Subject: Re: keyCertSign and cRLSign Key Usage Bits

From: "David P. Kemp" <[email-masked]>
Date: Tue, 24 Apr 2001 14:48:09 -0400

Russ,

With regard to keyCertSign:

I still don't see a definition of "CA certificates", so I still think
sentence 2 ("This bit MUST only be asserted in CA certificates.") should
be deleted.  Is the following true?

   If the cA bit or the keyCertSign bit is asserted, then the
   certificate is a CA certificate.
   If neither the cA bit nor the keyCertSign bit are asserted, then
   the certificate is not a CA certificate.

If those statements are true, then sentence 2 adds nothing except
confusion: there is the question of whether it is the identical
requirement to sentence 3 or a different requirement.

Sentences 3 and 4 are quite sufficient; sentence 2 should be deleted.

---------------------------------------------------------------------

The second paragraph assumes that we have consensus that the cA bit
should be used to determine which authorities can revoke which certs.
I don't believe there is consensus on that point.

Additionally:

* Sentences 1 and 2 are redundant; only one of them is needed.

* Sentence 3 does not contain any useful information about cRLSign.
(If the cRLSign bit is *not* asserted in a CA certificate, the cA bit
must still be asserted.)

* Sentence 4 is a policy statement unrelated to CRL signing. Do we have
consensus that a CA may not also be an AA?  If so, that policy should
be stated under attribute certificate issuance, not under key usage.

* Sentence 5 does not define "AA certificates".  Should an AA be able
to sign CRLs using a new key which lists ACs signed with the old key?
Should an AA be able to delegate CRL signing to a key that cannot sign
ACs?  (I believe the consensus is yes on both counts.)  If so, and if
PKIX is to have a testable requirement along the lines of your new
langage, then it must tell implementations how to recognize an
"AA certificate", including one that can revoke but cannot sign ACs.

* The final sentence is repeated verbatim from paragraph 1; does it have
any greater effect if written twice?

-------------------

I propose something quite close to the language in new-part1-04.  The
rest of your new cRLSign language is just fluff because there is no way
to determine whether an application complies with it.

        The keyCertSign bit is asserted when the subject public key
        is used for verifying a signature on public key certificates.
        If the keyCertSign bit is asserted, then the cA bit in the basic
        constraints extension (see 4.2.1.10) MUST also be asserted.
        If neither the keyCertSign bit nor the cRLSign bit are asserted,
        then the cA bit in the basic constraints extension MUST NOT be
        asserted.

        The cRLSign bit MUST be asserted when the subject public key is
        used for verifying a signature on certificate revocation lists
        (e.g., CRLs or ARLs).
            {If the cRLSign bit is asserted, then either the cA bit
             in the basic constraints extension or the the authority
             bit in the basicAttConstraints extension MUST also be
             asserted.}*

* The last sentence, in {braces}, is an example of how one might
write a testable requirement.  I don't actually believe it should be
included in 2459bis.

If PKIX wants to use the cA bit to control revocation, and it
is not going to profile X.509's SOAIdentifier or basicAttConstraints
extensions, then it MUST use something other than handwaving to
distinguish EE certs from AA certs.  That's why I don't believe there
should be any linkage between the cRLSign bit and the cA bit.

Dave

"Housley, Russ" wrote:
> 
> The consensus on these bits is not totally clear to me.  Yet, several
> points have been consistently, and I think that the following text
> incorporates them.  The debate regarding he linkage between these bits and
> the cA bit in the basic constraints extension does not seem to be over, and
> I have not made any changes in that area.  Please use this new thread to
> discuss any remaining unresolved points.
> 
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on public key certificates.  This
>        bit MUST only be asserted in CA certificates.  If the keyCertSign
>        bit is asserted, then the cA bit in the basic constraints
>        extension (see 4.2.1.10) MUST also 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 cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on a certificate revocation list (e.g.,
>        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
>        Authority (AA) certificates that are used to verify signatures on
>        CRLs.  If the cRLSign bit is asserted in a CA certificate, then
>        the cA bit in the basic constraints extension (see 4.2.1.10) MUST
>        also be asserted.  If the cRLSign bit is asserted in a AA
>        certificate, then the cA bit in the basic constraints extension
>        MUST NOT be asserted.  Such AA certificates MUST NOT be used to
>        verify signatures on CRLs containing revocation information for
>        public key certificates; however, these AA certificates MAY be
>        used to verify signatures on CRLs containing revocation
>        information concerning attribute certificates.  If neither the
>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>        in the basic constraints extension MUST NOT be asserted.
> 
> Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 15:51:53 -0400

Dave:

If the cA bit is asserted, then it is a CA certificate.  However, the 
keyCertSign and/or the cRLSign bits tell what the CA is going to do with 
this particular public key.

I have no problem deleting the second sentence.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 25 Apr 2001 08:47:15 -0400

Russ,

Thanks.

However, I am more concerned about the second paragraph than the
first.  Is Last Call the proper time to be proposing, discussing,
and ratifying such a novel and significant change to the path validation
algorithm?

       Such AA certificates MUST NOT be used to verify signatures
       on CRLs containing revocation information for public key
       certificates;  ...

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 26 Apr 2001 16:43:44 -0400

Dave:

This is not a change.  Rather, it complements the AC profile.  The AC 
profile says:

    The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
    extension in the PKC MUST NOT explicitly indicate that the AC
    issuer's public key cannot be used to validate a digital signature.
    In order to avoid confusion regarding serial numbers and
    revocations, an AC issuer MUST NOT also be a PKC Issuer.  That is,
    an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
    NOT have a basicConstraints extension with the cA BOOLEAN set to
    TRUE.

Since one issuer cannot issue both ACs and PKCs, then I would expect them 
to employ separate CRLs.

Are you suggesting that ACs and PKCs might be mixed together on one CRL 
using the indirect CRL mechanism?

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 30 Apr 2001 11:42:24 -0400

Russ,

I am not concerned about mixing ACs and PKCs on one CRL.  I am concerned
about unnecessary complexity in the PKIX spec and unnecessary changes to
X.509.  You have expanded the description of the cRLSign bit from one
sentence to six for no good reason.  As Steve Kent says, 

   "We need to make a decision on whether a cert without a CA flag
    enabled can sign CRLs.  If so, then we need to modify a lot of text
    in 2459, and X.509, to say this clearly."

There is no security benefit to changing the text.  For that reason, I
oppose making it more complex. 

Rationale:

1) Previously, conforming clients could validate a CRL if the cRLSign
   bit is asserted and the cA flag is not asserted.  This change
   would declare such clients to be non-conforming.

2) There have been discussions here regarding the necessity of
   distinguishing between "authority" certificates and "non-authority"
   certificates for CRL validation.  If the cA flag is to be used
   to convey "authority-ness" for CRLs containing PKCs, what is the
   equivalent mechanism PKIX clients are expected to use to recognize
   the "authority" for CRLs containing ACs?

   My position is that no additional flag is needed in either the CA or
   the AA case.  If the CRL signer has a valid certificate with the
   cRLSign bit set, then it is an authority because the certificate
   signer (or it's parent) has said so. Requiring two flags in the
   same certificate is no more secure than requiring one.

3) The quote from the AC profile does not make sense to me.  If an
   authority can sign both PKCs and ACs, surely it can guarantee that
   it will not assign duplicate serial numbers.  There may be good
   (operational) reasons for using separate keys to sign PKCs and ACs,
   but "confusion regarding serial numbers and revocations" isn't
   one of them.

Dave