Subject: RE: Absent keyUsage in certificates

From: [email-masked] (Peter Gutmann)
Date: Sat, 04 Jun 2005 05:35:32 +1200

"David Cross" <[email-masked]> writes:

>But many companies don't want to anticipate the purpose when they issue a 5
>year smartcard, etc.

Doesn't that work the other way as well though?  What if I issue a cert with
no keyUsage (i.e. all usage is OK) that's intended for throwaway use (signing
in to jokeoftheday.com, so I don't protect it much and may even hand it out to
friends) and six month later someone defines a new keyUsage bit
confessingToAssassinateThePresident?  You're assuming that allow-all for any
new usages will be a good thing, but it could quite well be that deny-all is a
better policy.

Peter.

---

From: Sam Roberts <[email-masked]>
Date: Fri, 3 Jun 2005 14:29:57 -0400

> new usages will be a good thing, but it could quite well be that deny-all is a

These are both good examples of why the decision about which is better
policy should be made by the issuer and/or receiver of the certificate
so that it works for them, not here.

Currently, both policies are possible.

  allow-all future usages == no KeyUsage

  deny-all future usages == KeyUsage with some/all current bits set

If KeyUsage becomes mandatory, wouldn't there have to be a new usage bit
allocated (allow-all-future)? And then validation apps would have to
understand that bit. And we would still have to understand absence of
KeyUsage meaning allow-all, because even if PKIX changes to require all
CAs to specificy KeyUsage, that isn't how it is now.

Also, as you well know, the MUST clauses for certificate generation in
PKIX are already widely ignored or misintepreted, and we have to deal
with those certs anyhow. Adding more generation MUST clauses won't help
us.

Adding text in PKIX that more clearly explains what the bits are for,
and what it means for the extension to not be present might be helpful.
Unfortunately, the longer (and possibly clearer) that PKIX gets, the
easier it gets to miss parts of it.

As an aside, I'm really happy with the NIST validation test suites.
Standards as complicated as PKIX without test suites are hard to
implement correctly.  With good test suites, particularly ones that test
negative as well as postive cases, help the chances of interop improve.

Cheers,
Sam

-- 
http://www.certicom.com

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 10 Jun 2005 21:39:21 +1200

Sam Roberts <[email-masked]> writes:

>Also, as you well know, the MUST clauses for certificate generation in PKIX
>are already widely ignored or misintepreted, and we have to deal with those
>certs anyhow. Adding more generation MUST clauses won't help us.

Yeah, fair enough.

>Adding text in PKIX that more clearly explains what the bits are for, and
>what it means for the extension to not be present might be helpful.

Hmm, I think there should then at least be a note in the security requirements
about the default allow-all behaviour of keyUsage, e.g.:

  If no keyUsage extension is specified, the certificate is assumed to be
  valid for any usage except certificate and CRL signing.  In other words if a
  CA forgets to add the keyUsage, the certificate usage fails open rather than
  failing closed.  In addition, new and unexpected usages may appear if
  additional keyUsage bits are defined after the certificate (with its allow-
  all default) is issued.

That at least warns users/CAs of the consequences of the default allow-all
behaviour.

Peter.