KeyUsage Clarifications (was Open Issue in Part1: path lengthconstraints)

[Aram Perez <aram@xxxxxxxxxxx>]

David P. Kemp wrote:

> I've never seen any benefit of the cA flag in the basicConstraints
> extension; it's just a vestigial appendix left over from when there
> was no keyUsage extension.
> 
> Consider the following certificates:
> 
> #  cA   CertSign  cRLSign    Effect
> - ----- --------  -------   ------------
> 0  F     0         0        End Entity
> 1  F     0         1        End Entity (can sign CRLs)
> 2  F     1         0        End Entity
> 3  F     1         1        End Entity (can sign CRLs)
> 4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
> 5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
> 6  T     1         0        CA, can sign certs
> 7  T     1         1        CA, can sign certs and CRLs
> 
> * As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.
> 
> Is there any benefit to having eight different certificate types
> instead of just four?   In my example of the online CRL signer, what is
> accomplished by setting CA=true (cert #5) instead of CA=false (cert #1)?
> You say you would set it to indicate that the CRL issuer is a CA, but
> what would the application do with that knowledge? (i.e. what would it
> do differently than if the CA flag were false?)
> 
> More generally, is there any reason why Section 4.2.1.10 should
> not also prohibit cert types 2 and 3? (in other words, require the
> keyCertSign bit to always equal the cA flag?).

A while back I requested wording that would clarify which combinations of
keyUsage bits are valid and which are not. I'm glad you are also raising the
issue, maybe something will be done about it this time.

Regards,
Aram Perez