From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
Exactly right. And, as Peter has pointed out yet again, there is a business
desire for "trust me after some out-of-band validation" certs that is so
strong, there are many examples IN USE TODAY of them. I'll trust him when
he says they are not interoperable; that certainly sounds likely to me.
Telling these people "don't use PKIX" is silly. We want as many people
using PKIX as possible so that application vendors don't have to support
two different cert formats to hold keys that are being used in the same way.
Paul,
I think you're a nice guy too :-), but I'm confused about exactly what
the "strong business desire" is for, and how it relates to the proposed
solutions.
I believe this thread began with a desire to *NOT* do out-of-band
validation, but instead to leverage the assurance provided by X.509
identity certificates (and the Internet X.509 PKI or a closed/local
X.509 PKI) to validate encryption keys. I'm certain that that is the
need expressed by Bill Burr.
I also believe that the need for encryption keys can be grouped into
two categories: protecting data at rest, and protecting data in
transit. IPSEC/IKE is one mechanism for protecting data in transit,
which uses identity certificates and uncertified key establishment
keys.
This message addresses protecting data at rest, similarly using
an encryption key with assurance inherited from a certified identity
(an X.509 signature certificate). It does not require any out-of-band
operations on the encryption key. It assumes that the out-of-band
operations related to establishing trust in the signature key are
already in place. Given that environment, it seems to me that it is
more appropriate to standardize a single mechanism and promote
interoperability in the data protection protocol - CMS - than in
the key certification infrastructure protocol - X.509.
Here's a simple proposal, involving the addition of one signed attribute
to CMS section 11:
----------------------------------------------------------------------
11 Useful Attributes
...
11.6 Public Key
The PublicKey attribute type specifies a public key which can be
referenced in lieu of X.509 certificates in the EnvelopedData content
type. This attribute is used to allow the message signer to specify
a public encryption key to be used in enveloped messages sent
to the signer.
The following object identifier identifies the PublicKey attribute:
id-publicKey OBJECT IDENTIFIER ::= { ... }
PublicKey attribute values have ASN.1 type PublicKey:
PublicKey ::= SEQUENCE {
kid SubjectKeyIdentifier,
keyInfo SubjectPublicKeyInfo }
SubjectPublicKeyInfo ::= SEQUENCE { -- Copied or Imported from X.509
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
----------------------------------------------------------------------
Note that almost no other changes should be required to the CMS specification
to enable the use of keys instead of certificates:
Section 6.1: "originatorInfo optionally provides information about the
originator. It is present only if required by the key management
algorithm." (OriginatorInfo contains certs and CRLs.)
Section 6.2.1:
rid EntityIdentifier,
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
"rid specifies the recipient's certificate or key that
was used by the sender to protect the content-encryption key."
Change:
"The EntityIdentifier is a CHOICE with two alternatives specifying the
recipient's certificate, and thereby the recipient's public key."
to:
"The EntityIdentifier is a CHOICE with two alternatives specifying the
recipient's certificate or the recipient's public key."
Add a line to the table in ESS Section 1.3.4 specifying that the
PublicKey attribute MUST be signed, and may be either Inner or Outer
in a triple-wrapped message.