I also agree that it is dangerous to try to add semantic meaning to the absence of
any extension, including key usage.
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of David A. Cooper
Sent: Friday, June 10, 2005 11:12 AM
Cc: pkix
Subject: Re: Absent keyUsage in certificates
I agree as well. I think this proposal has several problems.
First, the text states "if a CA forgets to add keyUsage, the certificate
usage fails ...." A more accurate statement would be that if the
keyUsage extension is absent from the certificate, then no restrictions
are imposed on the use of the subject public key except.... We cannot
say that the absence of a keyUsage extension equates to "a CA forgets to
add keyUsage" and the absence of keyUsage is not a failure. The problem
with making a statement about the absence of keyUsage is the "except
...." There are a number of things other than keyUsage that could limit
the acceptable uses of the subject public key:
1) If it is a version 3 certificate and the basicConstraints extension
is absent or is present with cA=FALSE, then the subject public key
cannot be used to verify signatures on certificates. If it is a version
1 or 2 certificate, the subject public key cannot be used to verify
signatures on certificates unless it can be verified through out-of-band
means that the certificate is a CA certificate.
2) A path length constraint imposed by a certificate earlier in the path
may prevent use of the subject public key for verify signatures on
certificates.
3) The subject public key cannot be used to verify signatures on CRLs
(or at least CRLs that will actually be used to determine the status of
a certificate) unless the subject has been authorized to issue CRLs
either because the subject is a CA and the CRLs cover its own
certificates or the subject is issuing indirect CRLs and has been
delegated that authority through the cRLIssuer field in a certificate
(section 6.3.3, step (b)(1)). [Note that there is no requirement for the
basicConstraints extension to be present to use the key to verify
signatures on CRLs.]
4) The use of the subject public key may be limited by the
certificatePolicies or extended key usage extensions.
5) The certificate could include a private extension that limits the use
of the subject public key.
If the keyUsage extension is absent, then it can be used for any
purpose, even for verifying signatures on certificates and CRLs, unless
that usage is restricted by some other means as described above.
Section 4.2.1.12 of 3280bis states "If the [extended key usage]
extension is present, then the certificate MUST only be used for one of
the purposes indicated." There is already text for keyUsage that
implies that the absence of the extension means no restrictions:
The key usage extension defines the purpose (e.g., encipherment,
signature, certificate signing) of the key contained in the
certificate. The usage restriction might be employed when a key that
could be used for more than one operation is to be restricted.
This implies that the keyUsage extension only needs to be present if
there is a desire to restrict the use of the key and so the absence of
the extension means the absence of restrictions. Would people prefer
for section 4.2.1.3 (Key Usage) to use language closer to the language
for extended key usage?
Dave
P.S. Since I have never seen any suggestion of any attempt to add new
bits to the keyUsage extension, I don't think we need to include a
warning related to that possibility. Besides, I would assume that a CA
that does not include keyUsage really does not intend to limit the usage
of the key (unless extended key usage or a similar extension were
included). I don't think one would leave keyUsage out of the extension
with the intention being to restrict the usage to the nine usages
currently specified in the keyUsage extension.
Stefan Santesson wrote:
>Peter,
>
>I don't like this text based on principles.
>
>An absent extension by itself does not provide any specific information
>at all.
>
>An absent extension only means that this information, constraints,
>guidance is not present.
>
>In order for any thing "absent" to have a meaning, there must be a
>default definition and in a way I could agree that the default usage
>for a cert is unrestricted. But then again, there are so many other
>ways to restrict the usage, that it is impossible to generally assume a
>default state just considering an absent key usage extension.
>
>There is also difference in what we require a CA to set and what a
>client should accept. Just because a compliant CA must set the cert
>signing key in a CA cert does not mean that my clients can't accept a
>CA cert that has an absent key usage extension (e.g. accepting a V1 CA
>cert).
>
>
>
Peter Gutmann wrote:
>Sam Roberts <sroberts@xxxxxxxxxxxx> 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.
>