RE: Self-signed root transport and CA expiration

[Peter Williams <peter@xxxxxxxxxxxx>]

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