Subject: Re: Certificate requests for encryption keys

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.