Subject: Certificate requests for encryption keys

From: Ilan Shacham <[email-masked]>
Date: Tue, 8 Jun 1999 19:39:04 +0300

There has been much talk lately of using dual key pairs - one key pair
for encryption, and one for signing.
The following question arises - how does one create a certificate request
for an encryption key pair? after all, the certificate request is signed by
the key inside it, but the key is an encryption key, so this is illegal.

I can think of two possible solutions to this problem -
1. For the purposes of certification requests, and for this purpose only,
the
encryption key could be used to sign.
2. First, a certificate is issued to the signing key, and then the signing
key
is used to sign the certification request for the encoding key. (But this
way
there is no Proof Of Posession of the encryption key).

It looks to me like the first option is better, but I couldn't find any
reference
to this problem in the PKIX drafts/RFC's. Is there such a reference? are
there any applications out there that confronted this problem?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[email-masked]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 8 Jun 1999 13:55:37 -0400 (EDT)

> From: "Bob Jueneman" <[email-masked]>
>
>  [...]
> 
> Our working, temporary expedient, along the lines of your #1,
> is to type the private key for both encryption and signature, but to 
> only turn on the encryption bit in the certificate.  But that's an 
> admittedly ugly hack.  Worse yet, it won't work at all with a 
> DH encryption key.
> 
> The real question is what are existing CAs prepared to support
> with respect to more advanced POP protocols?

You mean "more advanced protocols" such as the one defined in
PKIX RFC 2510/2511?  I believe there is at least one CA which
supports POP for key transport (RSA) and key agreement (DH or KEA)
keys in the standard manner.

---

From: Jeff Brinskelle <[email-masked]>
Date: Tue, 8 Jun 1999 14:20:38 -0400

I assume you are talking about PKIX-CMP and RFC 2510.
In which case according to the interop profile in 
> Appendix B8 of RFC 2510,  to initialize a user with 
> a verification and an encryption certificate, the 
> client should send an 'ir' with two CertReqMsg's, 
> the first one (certReqId = 0) must be the verification 
> request, the second one (certReqId = 1) can be the 
> encryption certificate request.
> 
> The message is protected using MSG_MAC_ALG, so 
> the senderKID is used to identify the client to the CA.
> 
> POP is necessary if the client generates the enc key 
> pair and does not include the encryption private key 
in the encryption request, in which case there are 
> options - indirect or direct POP (both described 
> in section 2.3 of RFC 2510).
> 
> 
> Hope this helps.
> 
> 
> 
> ----------
> From: 	Ilan Shacham[SMTP:[email-masked]]
> Sent: 	Tuesday, June 08, 1999 12:39 PM
> To: 	Ietf-Pkix (E-mail)
> Subject: 	Certificate requests for encryption keys
>

---

From: Keith Brady <[email-masked]>
Date: Tue, 08 Jun 1999 19:27:20 +0100

One approach is to make a CMP IR/IP pair for a signature key certificate
which will have the effect of creating an authenticated identity
(presumably). This information should be maintained at the CA and we can
then make a CR request, signed (or POP'ed) by the signature key with the
encryption key as the payload.

We are, of course, not POP'ing the encryption key but this probably
doesn't matter. 

One can do the same with PKCS#10 though you miss the option to use POP.

cheers,

Keith

---

From: Keith Brady <[email-masked]>
Date: Tue, 08 Jun 1999 20:15:29 +0100

> ??? If I HMAC then DH the result, isn't that a signature?

Um, not at all sure I understand you here. Don't we need a pre-agreed key
for the HMAC? I trust you mean hash. Not all encryption algorithms are
designed such that this is the ideal way to use them.

In any case I believe we are talking about El-Gamal rather than Key
Exchange D-H. In the general case, it is (I think) possible to construct
encryption algorithms where the hybrid approach (encrypted hash) doesn't
work. I did read something on this a good while ago but I can't remember
where.

cheers,

Keith

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 9 Jun 1999 08:22:45 (NZST)

Anne Anderson - Sun Microsystems <[email-masked]> writes:

>I would like to see any Subject, including an End-Entity, be able to issue
>certificates for encryption keys (and possibly other types as well).

I proposed this some time ago, but there didn't seem to be any interest in it.
Here's the message from last time...

Peter.

-- Snip --

Current X.509 profiles all require the presence of an arbitrarily large and
all-encompassing PKI to function properly.  Unfortunately this doesn't take
into account two very common cases:

1. Two parties who have an established trust relationship and want to share
   keys.  This is a very common case for businesses who would typically have
   existing bilateral trading arrangements and neither require, nor care for,
   an external (or internal) CA.  Keys for the other party would be held as
   part of the standard account records maintained by both sides, which would
   also contain information such as account balance information required for
   standard business practices).  Simply registering the other parties public
   key in the account record represents the easiest and most reliable way of
   managing the public key, whereas using a third-party certificate requires
   complex certificate handling, reliance on a third-party CRL, and the
   creation of an unnecessary parallel trust infrastructure which adds nothing
   (apart from complexity) to the existing trust mechanism.

   A typical example of this would be users who are submitting electronic tax
   returns: The tax department knows who its "customers" are, and *everyone*
   knows who the tax department is.  A CA doesn't even fit into this model.

2. An end entity who has a CA-certified authentication cert and wants to use it
   to issue their own confidentiality keys.  If an end entity has an
   authentication cert then there's no real need for CA-issued confidentiality
   certs, especially since this grants the end entity a far greater degree of
   control over their keys.  For example the end entity might wish to roll over
   their confidentiality keys once a month, a prudent security precaution which
   could end up bankrupting them if it were attempted with CA-certified keys.

Unfortunately both of these items, while perfectly sensible, represent a
paradox for X.509, since a certificate is incapable of representing them:
There's no way to create a standalone end-entity certificate containing a
public key, and there's no way for an end entity to create/certify their own
confidentiality keys.

The reason a standalone end-entity certificate can't exist is that it has to be
signed by a CA, but an end entity is by definition not a CA and therefore can't
do this.  A workaround is for the end entity to create a pseudo-CA certificate
whose only task is to sign other certificates, but all this does is add
unnecessary complexity.

The reason an end-entity certified confidentiality key can't exist is again
because an end entity isn't a CA, and again because there's no way to specify
this in a certificate.  It's possible to make the end entity a CA with a path
length of zero and a name constraint which only allows them to issue certs to
entities below them, but this isn't what's required, and it's unlikely that
current CA's will agree to turn each of their users into mini-CA's.

To solve the first problem, we require a means of specifying that the
certificate is a standalone self-signed end-entity certificate.  Unfortunately
this can't be done with X.509, the best we can do is add a special-purpose
extKeyUsage which notifies the relying party of this.  The certificate has the
usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = as usual, cert/crlSign bits not set
  extKeyUsage = selfSignedEndEntity

A problem with this is that certificates with the issuerName = subjectName are
regarded by a lot of software as self-signed CA root certs, so in addition to
this the issuer CN must be set to 'Owner-issued certificate'.  This isn't used
for identification purposes but to ensure that the certificate can't be
mistaken for a conventional self-signed one, which would be treated as a CA
root cert.

To solve the second problem we require two things, a means of specifying that
the certificate is an end-entity confidentiality-key-issuing cert, and a means
of handling confidentiality key rollover.  The confidentiality-key-issuing cert
has the usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = certSign set, others set as required
  extKeyUsage = endEntityIssuingCert

A cert with this key usage has an implicit name constraint which requires that
the subject/issuer DN of the confidentiality cert be the same as the subject DN
of the c-k-i cert.  This is required in order to avoid the c-k-i cert being
able to act as a general-purpose CA.  We can't use an explicit name constraint
because they're not allowed in end-entity certs, and in any case all we can
constrain with this is a subtree, not a fixed name.

The key rollover problem is solved by having a 'supersedes' extension in the
confidentiality cert which contains a unique identifier.  The sender takes the
most recent certificate containing this identifier and uses it to communicate
with the cert owner.  Note that the identifier can't be something like the
authorityKeyIdentifier, since (a) this could change over time, and (b) these
again aren't allowed to be present in end-entity certificates.

The intended application of confidentiality key rollover is as follows:

The cert owner communicates the c-k-i cert and confidentiality key cert to the
other party in the usual manner (eg as part of an S/MIME cert chain).  The
other parties softwware records the supersedes identifier and, when it wants to
communicate with the cert owner, takes the most recent cert with that identifer
and uses it for the confidentiality key.  The cert owner can roll over their
key by including a new confidentiality cert in their mail to the other party at
any time.

If the two parties don't communicate very often, it may occur that the other
party only has expired confidentiality certs.  In this case they can use a
long-term fallback cert for the first exchanged message to bootstrap
communications, after which they'll obtain the latest confidentiality cert in
the reply to their mail.

This use of end-entity certified confidentiality keys allows perfect forward
(and backward) secrecy (keys can be rolled over on a per-message basis if
required) which is completely transparent to the user, as well as doing away
with the need for the (unnecessary) reliance on a CA for certification of
confidentiality keys.  Note that this doesn't diminish the CA's business, since
they're still required to issue the authentication certificate, which will
expire after a set time and require renewal as usual.  It makes no difference
to their bottom line whether the CA issues a single long term cert or a
single-long term cert with the ability to issue many short-term certs, in both
cases they get paid for the one cert.

---

From: Hemma Prafullchandra <[email-masked]>
Date: Tue, 8 Jun 1999 14:39:13 -0700 (PDT)

> One can do the same with PKCS#10 though you miss the option to use POP.

For pkcs#10 based DH public key certification please look at
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-00.txt

We'll be publishing an update soon with some examples.

Hemma

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 8 Jun 1999 17:46:54 -0400 (EDT)

Bill,

I believe your first sentence contains the answer:  what you want is
a "signed" encryption key, not a "certified" encryption key.

If there is a need for long-term encryption keys certified by a third
party, then an X.509 certificate is the appropriate structure to
represent them.  But if there is a need for rapidly updated public
key-establishment keys, or no need for a third party to be involved in
certifying a longer term key establishment key, then why would one
choose to use an X.509 certificate in the first place?

As Steve pointed out, IKE (the IPSEC Internet Key Exchange protocol)
supports PFS.  I would also point out that TLS defines an Ephemeral DH
exchange using (by definition) non-certified public keys.

CMS (S/MIME) requires X.509 certificates for encryption because there
is no requirement for an envelopedData structure to be wrapped within
a signedData structure, thus the certificates used with envelopedData
must support both encryption and authentication.  But a hypothetical
non-S/MIME protocol could profile a mandatory wrapping of CMS
envelopedData within a signedData, and define a publicKeyInfo attribute
to hold the naked encryption key, eliminating the need for
X.509 authenticated-encryption certificates.

I believe the lack of sympathetic response to the suggestion of
EE-issued X.509 encryption certificates is well deserved.  Using an
X.509 Certificate structure to represent a non-third-party-certified
EE-signed public key-establishment key is like driving a screw with a
hammer.  You could do it, but why would you want to?

Dave Kemp

> From: Bill Burr <[email-masked]>
> Subject: Re: Certificate requests for encryption keys
> 
> Anne,
> 
> Your line of reasoning has always made sense to me.  If you can validate my
> signature, why wouldn't you trust me to sign my own encryption key?
> 
> Nevertheless, when I have mentioned the idea that end entities could
> self-sign encryption certificates, I don't think I've ever received a
> sympathetic response.  I think I've heard 3 arguments against self-signed
> encryption certificates:
> 
> 1. How can I revoke my self-signed encryption certificate except by
> revoking my signature certificate?  Relatively short lifetime encryption
> certificates would be at least a partial answer.
> 
> 2. How can the relying party know I truly have the private key?   But why
> do we need POP in this case?  I at least have never understood what the
> danger is to a relying party if I claim to own an encryption key I don't have.
> 
> 3. Such a system would make it hard to enforce a systematic data recovery
> discipline.   
> 
> Of course a practical objection is that X.509 type systems today just
> aren't set up to do it. In particular, the validation software would have
> to ensure that an end entity could only sign an encryption certificate for
> the same name.  We're really talking about something that goes a bit beyond
> X.509, I suppose.  I think the model of a self-signed encryption
> certificate is a fairly good one, but it's not quite what X.509 apparently
> contemplates.
> 
> Bill Burr

---

From: Alan Lloyd <[email-masked]>
Date: Wed, 9 Jun 1999 08:55:24 +1000

Some comments - Generally because the logic of this one seems wrong.
> -----Original Message-----
> From:	[email-masked] 
> Sent:	Wednesday, June 09, 1999 6:23 PM
> To:	[email-masked]
	This is because - X.509 is part of a directory authentication
framework that by defintion relies on and is defined by X.500 directory
based information objects and attributes -  that must exist  in a named
hierarchy - ie 509 relates to the authentication framework of an X.500
distributed directory information model that contains attributes (and
objects) that add security and trust mechanisms (CAs PKIs and Certs) etc
to this. 

>    knows who the tax department is.  A CA doesn't even fit into this
	So this is bi lateral - mutual out of band trust relationship  -
it is not directory based - PKI trust model.

	This is like arguing that a ship is not a car !

	However, most tax departments have done it this old way for the
last 2000 years - but now they are adopting PKI...

>    could end up bankrupting them if it were attempted with
	Again this does not reflect a natural hierachy of trust - or the
logic of what a CA or EE is.. ie an EE is just that and End Entity and
its certificate by definition cannot be used to verify issue or
certificates..
	Why debate that something which is identified at the end of the
line cannot do something which can only be done by something within the
line!

	 All one needs to make this work is make the entity that wants
to manage its own confidentiality keys NOT and end entity - ie a CA
function because it generates its own certs - it is by definition a CA
function..

	A CA is represented by additional attributes of a directory
object...

> public key, and there's no way for an end entity to create/certify
	There is no paradox for X.509 - there are just flaws in the
logic presented.

	snip

	If one wnats to build a PKI system as represented by an X.509
model in the context of a distributed directory service - everything
works
	If one throws away the directory information model and the
hierarchical rules of trust and CA functions identification that are
assigned to that directory model , etc  and create unrealistic
situations outside that - and then say these are flaws - IMHO the debate
is strange..

	I use my boat on the sea and my car on the roads - I understand
the modelling and engineering of these items to the extent that if  I
reverse their usage - nothing works - and costs me heaps :-)

	regards alan

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 09 Jun 1999 09:59:15 -0600

I think the subject is well worth exploring, but I am uneasy with relying 
on someone signing an unrelated encryption key without Proof of 
Possession.

I can't find a smoking gun, but that doesn't mean there isn't one--it may 
mean that I haven't thought about it hard enough.  Unless someone 
can somehow prove the negative (admittedly very difficult), I would
proceed very cautiously.

But proceed, nonetheless!

Bob

>>> Peter Gutmann <[email-masked]> 06/10/99 03:02AM >>>
Bill Burr <[email-masked]> writes:

>sympathetic response.

Given that there seem to be several people in this situation out there, is
there any interest in doing a profile for these certs?  It's pretty trivial
to implement given any existing toolkit, all we'd need is to achieve 
consensus on how the certs should be denoted.  Since there's no backwards-
compatibility issue, all you really need to do is convince enough people to
adopt the scheme.

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 9 Jun 1999 12:35:46 -0400 (EDT)

> From: [email-masked] (Peter Gutmann)
> 
> This is a general response to several messages which have pointed out that
> self-signed EE certs don't fit into the X.509 theology[0]... this is a valid
> point, however what people are trying to achieve with these certs is a means
> of sharing keys without external certification and authentication and fuzzy
> dice and chrome tailfins.  The X.509 format makes it impossible to just store
> or communicate a key without carrying a vast mountain of other (often
> unnecessary) baggage around with you.

Of course it does, and that's precisely the point of the messages you
refer to.  The difference between a car and a ship is not a theological
distinction, nor is the difference between an X.509 certificate (as
used in a PKI with external authorities) and a bare key (authenticated
by its owner).

If you want to send a key from A to B, why would you even consider packing
it up with X.509 baggage (DN, validity, serial#, issuer, blah blah blah)?
You might store the key and its parameters using a structure borrowed
from X.509 (call it PublicKeyInfo instead of SubjectPublicKeyInfo), but
don't try to use the cruise ship to travel to the local grocery store.

If the goal is to send a signed key without using the IETF standard for
signed objects (CMS), then here's a free piece of ASN.1 that might
do the trick:

  signedKey ::= SEQUENCE {
     tbsKey              PublicKeyInfo,
     signatureAlgorithm  AlgorithmIdentifier,
     signatureValue      BIT STRING }
     
  PublicKeyInfo ::= SEQUENCE {
     algorithm           AlgorithmIdentifier,
     publicKey           BIT STRING }

Please use CMS, or IKE, or TLS, or whack on this structure until it does
what you want.  But DON'T try to use X.509 and then complain that
it wasn't designed for the purpose.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 09 Jun 1999 12:15:25 -0600

Fallacy, perhaps, but not intentional.  :-)

I was neither agreeing nor disagreeing with what Anne said, 
merely urging caution, having been around this particular maypole 
a number of times over the last N years.

But Steve said it better. Security is hard -- be very careful.

Or as Einstein said "For every problem there is a simple solution.
Unfortunately, most of the time the simple solution is wrong."

Bob

>>> Michael Sierchio <[email-masked]> 06/09/99 10:37AM >>>
Bob Jueneman wrote:

> In the case of a digital signature, not requiring proof of possession would
> allow me to get of copy of Thomas Edison's public key (small time wrap
> problem omitted for brevity) and claim all of his digitally signed patents
> as my own.  (Assuming he didn't actually include his name
> in the patent itself, of course.)
> 
> What kind of mischief could someone carry out with an encryption key
> without POP?

I think you're engaging in intentional fallacy --

Anne's scenario includes:

	1)	an EE signing cert,  with identity attested to by appropriate
		RA, CA and the Pope, perhaps restricted in use to signing 
		encyption-only certs with half-life in seconds;

	2)	a signature over a (possibly ephemeral EE encryption cert),
		attesting to its validity, by the EE;

	3)	ability to perform encryption after (2) is proof of possession of the
		private key;

	4)	ability to sign this cert with (1) is proof of identity.

If I were to sign a message stating "for the next two hours,  I will use
the following DH parameters for communication with Anne..." it would be
equivalent.  The difference is the ability to cook an X.509 cert which
would permit key discovery through "normal" means,  quite convenient.

A self-signed cert contained in a message signed by my signing key is also
somewhat equivalent.  I like Anne's approach better.

Cheers,

Michael Sierchio

---

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 9 Jun 1999 16:05:07 -0400

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Wednesday, June 09, 1999 11:59 AM
> To: 	Stephen Kent; [email-masked]
> Cc: 	[email-masked]
[snip]

> The fact that one gets X.509 self-signed root certs from a 
> directory and then does out-of-band verification says to me that there is 
> no good reason not to get self-signed EE certs from a directory if they
> are 
> then followed by out-of-band verification. If we can set up a different 
> profile of X.509 to allow the latter case, we should do so, given the 
> obvious business desire for such a system.
> 
Since the EE issuing a self-signed cert is a de facto "do-it-yourself-root
CA," and since the objective is to get self-signed EE certs from the
directory of another self-signing root CA, are we not just talking here
about root-CA cross certification?  If we are, are you suggesting a
cross-certification profile of X.509?  And if we are, is there really an
"obvious business desire for such a system"?

Bill Flanigan

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 10 Jun 1999 08:15:16 +1000

Some more comments -

> Sent:	Thursday, June 10, 1999 1:04 PM
> To:	[email-masked]
	No it does not - one does not have to use a CA hierarchy of
trust with X.509 certificates  - if a common trust point is achieved by
other means or implied.
	If you dont want to obey the processing and entity definitions
of what has been standardised as an EE within a hierarchy of trust -
then dont.
	But dont say that the standard EE is at fault when you use it in
a non standard way.

	If you want to do non standard things - dont blame the
standard...
	PKI and Certficates are about information objects that tie NAMES
to key material in a shared named based system with a common point of
trust - 

	With what mechanism are you verifying names - without a PKI?.

>  I can't speak for others who have 
> posted an opinion on this, but all I'm trying to do is get a key from
> A to B
> without requiring a huge (and currently mostly nonexistant)
> infrastructure to
> do it, the same thing which PGP has been doing very successfully for
> nearly a
> decade.  All I want to do is store a key in a non-proprietary format,
> but 
> X.509 (currently) doesn't let me do that unless I get a CA to sign it
> first.
> 
	A CA is a function - not a global infrastructure - A CA can be a
bus ticket vending machine...

	Whats the operational requirement and points of trust?

	Regards alan
> I'm proposing is a key bit-bagging scheme which isn't entirely
> dependent 
> on the presence of a CA in order to function.
> 
> Peter.
> 
> [0] Whether X.509 is systematic or speculative theology is left for
> the reader
>     to decide :-).

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 11 Jun 1999 11:01:09 -0400 (EDT)

> From: Paul Hoffman / IMC <[email-masked]>
> 
> 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.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 12 Jun 1999 05:57:32 (NZST)

>I'm confused about exactly what the "strong business desire" is for, and how 
>it relates to the proposed solutions.

Since the distribution now includes new people (ietf-smime) I'll give the 
Readers Digest version of what I said in an earlier message:

1. Free or low-cost certificate tools are becoming more and more widespread.
2. Businesses are using these more and more: "The software's free, we have
   the expertise to do it in-house, why do we need to pay a CA for it?"
   (Classical manglement thinking at work).

The problem with this approach is that X.509 doesn't define a format for:

1. A standalone end-entity certificate verified using out-of-band means.
2. An encryption-only cert signed with an end-entity signature-only cert
   verified via the usual CA mechanism.

Both of these results are what businesses are trying to do based on the
manglement thinking presented above, with the result that you end up with
whatever cert kludges are required by the toolkit they're using to make this
possible (eg everyone is a CA and signs their own certs, a single certificate
vending machine-type app is used to sign everyone's certs just to get the 
public key into X.509 format, someone is appointed to generate everyone's keys
for them so they can sign the public portion with a fixed CA cert before they 
send them out to the users(!!!), etc etc etc).

The result was a thread containing various ways to achieves this, with no
clear consensus being reached (several people had done it, but their ways
of doing it were all different).

>Here's a simple proposal, involving the addition of one signed attribute to 
>CMS section 11:

That's a nice way to do it using existing mechanisms, but it's almost but not 
quite completely unlike the required solution :-).  What people are trying to 
do is create certs managed through means other than the full CA 
infrastructure, and use the resulting certs (full certs, not just raw public 
keys) with web servers, in custom signing applications, in EDI software, and 
God knows what else (for example I know of one company who do a web-browser
plugin which signs data sent from the user back to a central server where 
noone's going to pay a CA for a cert when the entire app with an infinite-user
license sells for a few hundred dollars.  In this case they're going to set up
every user as a CA with their own self-signed CA cert, and the software is 
coded to treat them as EE certs.  The reason I know about this particular case
is that they're using my software to do it, and since I'm pretty picky about 
doing things the way PKIX requires the only way they could get self-issued 
certs to work is to make everyone a CA.  I don't know whether they've released 
this yet, but from talking to them in the past they're going to end up with a 
fair number of users, and there are many other companies doing things this way
as well).

As I see it, there are three options:

1. Define a format for the two cases described above and try and get 
   developers of toolkits and whatnot to stick with it, so that when people
   do employ these certs you can identify them and work with them as required
   (which could include just refusing to handle them if you feel so inclined).
2. Educate every IT person on the planet about the wonders of X.509 and
   convince them all to do it the way they're supposed to do it rather than in
   a way where they can ship a product as quickly and cheaply as possible.
3. Continue to ignore the issue and end up with an ever-increasing number of 
   homegrown kludges which at best won't interoperate with anything else and
   at worst will severely screw up any other software which tries to use it.

Peter.