Subject: Basic Constraints and Key Usage

From: Tom Gindin <[email-masked]>
Date: Mon, 19 May 2008 22:25:43 -0400

I suggest that it is best practice for a CA to include a Key Usage 
extension in any certificates it issues which contain the CA flag in the 
Basic Constraints extension set to true.  RFC 5280 section 4.2.1.3 already 
requires that any certificate used for certificate or CRL signing contain 
KeyUsage.  Section 6.1.4 steps k and n permit the acceptance of a 
certificate with Basic Constraints.CA true but with KeyUsage absent as a 
valid intermediate CA certificate.
        If the private key of such a certificate is later compromised, the 
illegitimate possessor of the private key can issue certificates which 
might pass verification.  If the KeyUsage extension is set in a CMP server 
certificate, such an illegitimate possessor would not be able to issue 
certificates.  It's a smaller exposure than the one where end-entity 
certificates were used as certificate issuers, because there are many 
fewer CMP server certificates and the like than there are end-entity 
certificates, but it's the same kind of exposure.  Not all Relying Party 
software checks revocation on intermediate certificates.

                Tom Gindin

---

From: "Todd E. Johnson" <[email-masked]>
Date: Tue, 20 May 2008 18:37:21 -0400

Hello Tom,

I am somewhat confused.  If the private key is compromised, the 
certificate should simply be revoked with the CRLReason of 
keyCompromise.  You simply rekey, move on, and place no trust in 
anything signed by the compromised keys after InvalidityDate.  Perhaps I 
over simplify this in many ways, however, it may be that I completely 
misunderstand your point.

To your last sentence, and the reason I felt compelled to reply:

It appears to me that RFC 5280 section 6.1.3 requires "at the current 
time" revocation checking MUST occur for "certificate i (for all i in 
[1..n])".

I personally feel that Relying Party software that does not perform this 
very basic check is simply a waste of time, since it appears the 
software is only "partially" performing "Basic" certificate processing. 
  I would imagine this would also be considered best practice on the 
part of the relying party.  (I.e., The Issuer can claim "Well, we 
provided the revocation data, the relying party simply didn't check!")

I had to re-word the above sentences quite a few times in order not to 
appear too critical of software developers whom don't check the entire 
path for revocation.

-- 

Regards,

Todd E. Johnson

---

From: "Todd E. Johnson" <[email-masked]>
Date: Tue, 20 May 2008 22:30:14 -0400

Hello,

I assume keyUsage is best practice, perhaps a bit too much since I like 
to ensure it is asserted critical, in every certificate issued by the CA.

However, is this more of an implementation issue?  If the the risk is so 
great, would ephemeral signing keys be too silly?

Santosh Chokhani wrote:
> I do not have problem with Tom's preference for using key usage.
> 
> In personal exchange, I shared the same concern with him.
> 
> May be what Tom means is that the CMP Server key may not be as well
> protected as certificate signing key and without key usage in it, an
> undetected compromise of less protected key can lead to bigger or easier
> damage due to lack of key usage limitations in the certificate. 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Todd E. Johnson
> Sent: Tuesday, May 20, 2008 6:37 PM
> To: Tom Gindin
> Cc: pkix
> Subject: Re: Basic Constraints and Key Usage
> 
> 
> Hello Tom,
> 

-- 

Regards,

Todd E. Johnson

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 20 May 2008 20:08:31 -0400

-----Original Message-----

Hello Tom,

-- 

Regards,

Todd E. Johnson

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 21 May 2008 07:19:46 -0400

I agree that this should be treated as an implementation issue.

Thus, a short discussion of this topic is appropriate for the Security
Considerations section of 5280.  The current RFC does not treat this
issue.

Separately, I noted that 5280 sings the virtues of self-issued
certificates in Security Considerations without discussing their
inherent security flaw and mitigation (see my paper in 2005 or so NIST
PKI research conference).  A short treatment of pitfalls of self-issued
is also warranted.

-----Original Message-----
From: Todd E. Johnson [mailto:[email-masked]] 
Sent: Tuesday, May 20, 2008 10:30 PM
To: Santosh Chokhani
Cc: Tom Gindin; pkix
Subject: Re: Basic Constraints and Key Usage

Hello,

I assume keyUsage is best practice, perhaps a bit too much since I like 
to ensure it is asserted critical, in every certificate issued by the
CA.

>> certificate with Basic Constraints.CA true but with KeyUsage absent
as
> a 
>>         If the private key of such a certificate is later
compromised,
> the 

-- 

Regards,

Todd E. Johnson