Subject: Re: cA flag and CRL issuers

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 30 May 2001 16:44:50 -0600

>I argue the RP has a right to declare the CA-issued certificate to be "null 
>and void", and to be able to promote this declaration throughout the 
>organization.
>
>Perhaps this "should" be accomplished by having the RP-organization-as-CA 
>issue its own certification for every public key of possible interest, in 
>which case it could revoke according to the present mechanisms, and 
>everything "works".  To ensure that third-party certifications are (by 
>default) untrusted, it would need to purge the vendor-installed default 
>root certificates from its systems.
>
Tony, I completely agree with you, but I would point out that although having the RP organization issue its own certification for all public keys of interest might be technically do-able, it certainly wouldn't scale beyond the boundaries of that organization. Once you start trying to manage the public keys of all of the employees of your extranet partners, you are out of the frying pan and into the fire from a management and control aspect.

Fortunately, revocation of particular certificates can be done on an exception basis, without having to (re-)issue all of the certificates directly, and that is my point.

Bob

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 30 May 2001 17:17:50 -0700

At 04:44 PM 5/30/01 -0600, Bob Jueneman wrote:
> >everything "works".

>Fortunately, revocation of particular certificates can be done on an 
>exception basis, without having to (re-)issue all of the certificates 
>directly, and that is my point.
>
>Bob

:)  That is mostly why "should" and "works" are in quotes.  The scheme is 
hardly workable except in a very limited arrangement.

My concerns also joined with that of CA root-key compromise.  I suppose a 
CA that issues a CRL listing its own signing key as revoked *can* be 
trusted (if it too signed the CRL) since either the CA intended to revoke, 
or the key is in fact compromised.  Ala SPKI "loop-of-trust", wherein 
authority begins (and ends) with the Relying Party, I sought to allow any 
party of authority to act as a "CA over the CAs" by "certifying" their root 
keys, and thus to be able to revoke them if desired, to address the root 
compromise problem for a "Relying Community".  That community would (once) 
install this super-CA root in its user's software.  Thereafter, if a CA 
needed to issue a new root upon compromise, the "authority" of each 
community could seek out that CA and certify that new key via the 
"community root".  This would allow the end user software a path to 
"accept" a new CA root electronically, since it would verify with the 
installed community key.

This mechanism reduces manual intervention in the N systems to only those 
operations that concern a community's trust in it own authority.

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900