Subject: Re: Certificate requests for encryption keys

From: [email-masked] (Peter Gutmann)
Date: Thu, 10 Jun 1999 07:59:47 (NZST)

Al Arsenault <[email-masked]> writes:

>It's actually very straightforward.  In fact, we implemented it several years
>ago.

And so, I suspect, has half the rest of the planet :-).  All in incompatible
ways.

>(2) change the rules so that

That's one way to do it, but pretty much any way is fine as long as you choose
a consistent interpretation and stick with it.

>But, after doing all of this, the question that arises is the one already
>posed by Dave Kemp:  why do you want to do this?  Certainly, I can understand
>financially-based desires - for security reasons, you want a new key
>management certificate every month, or every day, and you don't want to pay
>$24.95 or $159.95 everytime you get one. But that doesn't strike me as being
>a good reason to change a technical system so dramatically.

I'm not asking for any great change, merely the opportunity to store and/or
exchange a key without requiring all the usual CA baggage which X.509 currently
requires.  Define a format and let the market decide - if there's really no
demand then, as the style guide says, "It will founder upon the rocks of
iniquity and sink headfirst to vanish without trace into the seas of oblivion".

I mentioned earlier that I've seen a number of organisations who are using
self-signed certificates, this process works roughly as follows:

Management, stage 1:

  "We need to use certificates" (they generally don't know why, but they know
   they need to use them for something).

Management, stage 2:

  "Look at these prices!  And we have to pay this each year for all 50,000
   users... we should have the expertise to do this in-house".

Overworked sysadmin who didn't run fast enough when he heard the key phrase "we
    should have the in-house expertise":

  [Playing with whatever that certificate program is which MS ships free with
   MSDN, or whatever mechanism it is they use to get it into every Windows shop
   on the planet]
  "We can issue our own certificates, and it'll cost us nothing.  It took me
   awhile to find, but if you set it up like this (self-signed certs) it works"

Management:

  "Very good.  Have a scooby snack".

I realise that this is probably great news for Microsoft and less great news
for people pushing CA's and CA software, but that's the situation I've found
God knows how many times when talking to smaller companies who are playing with
the use of certs.  I'm sure that if MS added some standard option to create
self-issued EE certs with one or two mouse clicks, half the Windows shops on
the planet would be using nothing but these certs (free and self-issued) within
a few service packs time.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Jun 1999 12:34:40 -0400

Peter,

Your description of the problem, and the home grown solutions does not
sound that far off from what I suggested.  A self-signed CA cert is just as
legitimate in a local setting as are the self-signed CA "root" certs built
into the browsers.  I see no need to change anything to accommodate this
approach of creating PKIs.  Note that several of the complaints that your
think IT managers may cite are common misperceptions, e.g., the need to pay
a third party to create certs for all of your staff, and to pay again every
year. This may be the VeriSign model of business, but it is not intrinsic
to X.509 nor to PKIX.

So, given the growing availability of cheap or free CA software (which
usually does not scale well notr have all the nice features of the more
costly stuff), why nit follow the approachj I suggested, create self-signed
a CA cert, and issue EE certs under it as a means of facilitating the key
exchange that is the desired goal?  if client software is designed to work
in such environments, which it should be if PKIX compliant, then one can
piggyback on this software, which is also everyones goal, right?  That
seems preferable, and more amenable to scaling that developing changes to
the standards and changes to client software to accommodate an OOB
distriubution mechanism other than one based on self-signed CA certs.

steve

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 11 Jun 1999 10:52:38 -0500

Adding subscriber-issued X.509 certs is a
perfectly reasonable value-add. As Steve
says, however, one way to accomplish this, and it
works today, is for each S/MIME user
to subscribe to a licensed legalistic CA
to obtain a msg-signing capability; and then
use that S/MIME signed msg to distribute
their own unlicensed, self-signed CA cert around the
world to register their own
domain with whoever can receive S/MIME
messages, and learn authoritative
trust-points contained in the signed content.
Today this community is at least the size
of the modern Windows-using population....
via MSIE and Netscape Communicator.

Nothing in the VeriSign CPS prohibits
this behavior, BTW. ("this" = use
S/MIME and verisign certs to
authoritatively distribute self-signed
public keys)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Peter Gutmann
> Sent: Thursday, June 10, 1999 8:00 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Certificate requests for encryption keys
>
>