RE: Open Issue in Part1: path length constraints

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Steve, we use the Indirect CRL/Indirect delta CRL format to
propogate revocation information for particular CAs between
our VAs (Validation Authorities).

Basically, as master VA can receive information that a particular
cert was revoked at a CA (even if the CA has not had time to
issue a new CRL as yet). It can (and does) create a Indirect
CRL with this information that it signs. The VA never acts
as a CA - it never issues certs, but still needs to be
responsible for creating and propogating revocation information
to other VAs.

While we use these indirect CRLs to propogate information just
amongst VAs, it is not a stretch to seeing clients trust these
indirect CRLs for their own purposes.

Hope this helps justify why it does make sense for non-CAs to
still issue CRLs.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Stephen Kent [mailto:kent@xxxxxxx]
> Sent: Tuesday, March 06, 2001 11:43 AM
> To: David P. Kemp
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> >Steve,
> >
> >I think of a "CA" as some people in a room with a Safekeeper.
> >If a CA wants to run its certificate signing functions on a machine
> >with no network connections, and it's CRL signing functions on a
> >network-connected machine, wouldn't that CA issue a certificate
> >to its CRL-signing key signed by its certificate-signing key?
> 
> I agree that there is ambiguity in what we mean when we refer to a CA 
> in such circumstances, but algorithmically I have always assumed that 
> only CAs issued CRLs and we can tell whether the entity is a CA by 
> the basic constraints extension. I see there is considerable 
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
> not yet sure I understand why folks consider it important to not turn 
> on the CA flag in certs for such entities. After all, since we have 
> separate key usage bits for cert and CRL signing, we can construct a 
> cert for an entity that signs CRLs and not grant that entity the 
> ability to sign certs, if we so desire.
> 
> As for your example, I would have expected the CA to accomplish the 
> same effect by having a second cert, with the same name, but with a 
> different key and with the key usage bits set to indicate CRL signing 
> but not cert signing. In that case, I would have expected the cert 
> for this second instance of the CA to have the CA flag set to true.
> 
> >If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> >isn't the subject of the certificate "a conforming CA"?
> 
> Not by my understanding.
> 
> >When X.509 says "keyCertSign: for verifying a CA's signature on
> >certificates", doesn't "a CA" refer to the people with the signing
> >machine, not a public key in a certificate with cA=true?
> 
> I have adopted a more restrictive interpretation, but I can be 
> persuaded otherwise IF I get a good answer to the question I posed 
> above.  Also, if we are to accommodate non-CA-flagged entities 
> signing CRLs, we need to chnage the text in 2459bis in a lot of 
> places and make this very clear up front.
> 
> Steve
>