RE: Self-signed root transport and CA expiration

["Hoffman, Mort" <Hoffman@xxxxxxxxxxxxxxxxxx>]

Peter,

I confess to being a little confused.  It seems to me that at the top of
every certificate chain, there must be a certificate (unless the chain
is null).  Now, that certificate must be signed (or it is not a
certificate).  It can be signed either by its own key (the evil
self-signed key) or another key.  Leaving aside the possibility that
this other key is below the certificate in the chain, it could be signed
by a key above it.  Since no key above it has a certificate (by
definition) it must be a private key without a public certificate.  In
any event, I would contend that it is the root or the private key
associated with a self-signed certificate is the root.

Given this somewhat pedantic argument, I am left to conclude that you
mean that Verisign has not one root, but a multitude of roots for
different products and/or customers.  Or else you meant that you do not
have a root certificate (which would make sense in line with your
statement that the root cannot expire, although private keys can expire
separately from associated public keys, but probably not what you
meant).

In either of these interpretations, I don't understand how your comments
address the issues which you were responding to.  Perhaps there is
another interpretation I am not thinking of.  Could you clarify for me
so that I can understand the point you are making?

Thanks,

Mort

P. S. on the original question, I see self-signed root certificates as
providing integrity, and may make it easier for software to chase a
certificate chain (and identifying its end-point).  It also provides
identification data which may assist with authentication, although
certainly cannot provide authentication by itself.

>----------
>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Tuesday, November 19, 1996 3:04 PM
>To: 	ssl-talk@netscape.com; ietf-pkix@tandem.com
>Subject: 	RE: Self-signed root transport and CA expiration
>
>There is no VeriSign root. It cannot expire, therefore. We
>were very careful to stay out of the militeristic hierachy
>path; the danger of some govt hijacking it capabilities 
>were far too great.
>
>The people who want to operate grand-unified roots tend to have 
>big-brother or domination motives; often they seek some defense contractor to
>enforce big-brother on their behalf. 
>
>Ive realised possibly why the debate on formal naming has emerged -
>so DN and cert type technology can be used to instrument the
>dormant encryption capability, where a cert from both
>govts is required.
>
>Does anyone know if KEA enforcement is being used
>to join the two distinct control systems,
>and if capstone/keystone has been altered to
>faciliate this? It could be used in a variation of the LEAF
>technology, used for access to raw capability on
>th Fortezza card, versus data.
>
>In terms of PKIX profiling, is there now a mission to
>instrument this "non-internet-purposed" control sytems using
>the cert profile?
>
>Perhaps we need to ensure that subject DNs are NOT
>mandatory for conformance, to assure the public
>the internet stds are not simply being engineered to enable
>govt control systems (without open debate, and concensus, at
>least).
>
>(Personally speaking, I really dont want the IETF to be enabling some
>dictatorial govt to impose controls like this on dissenting people! Let <X>
>and <Y>
>et al enable apartheid-enforcing pass-book controls systems and
>the like; not the IETF!)
>
>
>----------
>From: 	David P. Kemp
>Sent: 	Tuesday, November 19, 1996 6:11 AM
>To: 	ssl-talk@netscape.com; ietf-pkix@tandem.com
>Subject: 	Re: Self-signed root transport and CA expiration
>
>
>> There's been some discussion recently on whether it is appropriate to
>> include self-signed root CA certificates in a certificate chain being sent
>> to support a particular certificate. (I've seen this both with respect to
>> S/MIME and SSL.) One point in support of sending roots, which I haven't
>> seen mentioned, is the question of resolving CA keys.
>
>
>Tim,
>  I'm missing something in the context of this question - what is the
>purpose of sending the root CA certificate?
>
>Since the receiver of the certificate chain must validate the 2nd 
>(1 level down from root) cert with the root's securely-configured
>public key (i.e. not a putative root key received on-the-fly), what
>is the benefit of *ever* sending the root cert as part of a chain?
>
>In 1999 when the Verisign root expires, it's probably best to install
>the new root cert using the same procedure the old one was installed
>with in the first place (verifying fingerprints from a newspaper
>ad, physical transport, or whatever).  Anything else is just
>begging for trouble.
>
>        dpk
>
>
>
>
>
>