Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments

["David A. Cooper" <david.cooper@xxxxxxxx>]

Dave,

I agree with you. I see no basis in X.509 for setting the cA flag in basicConstraints for certificate subjects that can issue CRLs but not certificates. The current discussion about how to deal with CRLs for attribute certificates vs. public key certificates just further goes to show that it was a mistake to suddenly change the rules at the last IETF meeting.

I must say, though, that I am still confused about what is the correct thing to do when dealing with attribute certificates. If the subject of a public key certificate can issue attribute certificates but not public key certificates, what bits in the key usage extension should be set? My understanding is that the keyCertSign bit should not be set, but this seems to leave digitalSignature as the next best option.


At 01:08 PM 4/18/01 -0400, David P. Kemp wrote:
>P.S., my preference is to not use the cA bit to make a distinction
>between types of CRL signers, in which case the text is much simpler:
>
>       The cRLSign bit MUST be asserted when the subject public key is
>       used for verifying a signature on a CertificateList (e.g., a CRL).
>       
>       If the keyCertSign bit is asserted, then the cA bit in the 
>       basic constraints extension (see 4.2.1.10) MUST be asserted.
>       If the keyCertSign bit is not asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.
>
>Dave
>
>
>
>"David P. Kemp" wrote:
> > 
> > The 9:25 AM version was clearer.  This version adds a restriction on
> > which type of authority may sign which type of revocation list.  Neither
> > version defines "CA certificate"; my impression was that
> > 
> >   If the cA bit is set, then the certificate *is* a CA certificate,
> > 
> > not the backwards-sounding
> > 
> >   If the cRLSign bit is asserted in a CA certificate, then the cA bit
> >   MUST be asserted.
> > 
> > How about the following:
> > 
> >       The cRLSign bit is asserted when the subject public key is used
> >       for verifying a signature on a CertificateList (e.g., a CRL).
> >       If the cA bit in the basic constraints extension (see 4.2.1.10)
> >       is not asserted, then the public key MUST NOT be used to verify
> >       signatures on CRLs containing revocation information for public
> >       key certificates, however it may be used to verify signatures
> >       on CRLs containing revocation information for other types of
> >       certificates (e.g., attribute certificates).
> >    *  If the cA bit is asserted, then the public key MUST NOT be used
> >    *  to verify signatures on CRLs containing revocation information
> >    *  for certificates other than public key certificates.
> > 
> >       If the keyCertSign bit is asserted, then the cA bit in the basic
> >       constraints extension MUST be asserted.  If neither the cRLSign
> >       bit nor the keyCertSign bit are asserted, then the cA bit in the
> >       basic constraints extension MUST NOT be asserted.
> > 
> > The third sentence (marked ***) is new; I don't know if you intended
> > the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
> > revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
> > then the third sentence is needed.
> > 
> > Dave