Subject: 3280bis issue: checking keyCertSign bit in path validation

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 19 Nov 2004 19:06:10 +0800

RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 19 Nov 2004 11:28:44 -0500

I do not believe that this is a place where 3280bis needs to change.

There are many places in which RFC 3280 imposes requirements for the
issuance of certificates that are not imposed by X.509.  But, RFC 3280
does not include corresponding checks in section 6 because RFC 3280
does not attempt to declare that a certificate (or certification path)
that would be valid under X.509 is invalid simply because the
certificate was not issued in accordance with the RFC 3280.

This shows up in a number of places.  For example:

X.509 states that the certificate serial number is an integer;
RFC 3280 requires CAs to use only non-negative integers that are at
most 20 octets long.

X.509 states that the basicConstraints extension may be critical
or non-critical; RFC 3280 requires that the extension be critical in
intermediate (CA) certificates.

In the case of keyUsage,  RFC 3280 imposes the requirement that you
quote below, X.509 does not.  If the keyUsage extension is not present
in a certificate, then no restrictions are imposed on the use of the
certificate (i.e., it would be the same as if the extension were
present and all bits were set to 1).

Note that keyUsage is different from basicConstraints, where there is
both an issuing and validation requirement.  That is, a version 3
certificate with no basicConstraints extension is effectively the same
as a version 3 certificate with a basicConstraints extension with
cA=FALSE.  X.509 states:

NOTE 1 - If [the basicConstraints] extension is not
present, or is flagged non-critical and is not recognized by a
certificate-using system, then the certificate is to be considered an
end-entity certificate and cannot be used to verify certificate
signatures.

So, X.509 imposes a requirement for the basicConstraints extension to
be present in version 3 intermediate certificates, but it does not
impose such a requirement for any other extensions.  The language in
section 6 of RFC 3280 is based on this.

Dave

Wen-Cheng Wang wrote:

The text says:

That means:

Wen-Cheng Wang

---

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Nov 2004 12:29:21 -0500

David,

Maybe we should add a statement in 3280bis that
says clearly that relying parties SHOULD NOT
attempt to enforce every requirement or
recommendation that RFC 3280 places on certificates.
They SHOULD only enforce those that are required
by the algorithm in section 6 or other requirements
that they have determined are necessary for their
particular situation.

I have heard several knowledgable people say that
their code rejected a cert because it didn't comply
with some requirement of RFC 3280 even though that
requirement is not in section 6. While this sort
of behavior for a relying party is not prohibited
under RFC 3280, it should be discouraged. We don't
need to have vigilantes running around rejecting
certs because their serial number is too long!

Thanks,

Steve

David A. Cooper wrote:

> does not include corresponding checks in section 6 because RFC 3280 does 
> not attempt to declare that a certificate (or certification path) that 
> would be valid under X.509 is invalid simply because the certificate was 
> not issued in accordance with the RFC 3280.
> 
>    1.
>       RFC 3280 requires CAs to use only non-negative integers that are
>       at most 20 octets long.
> 
>    2.
> 
>       or non-critical; RFC 3280 requires that the extension be critical
>       in intermediate (CA) certificates.
> 
> certificate (i.e., it would be the same as if the extension were present 
> and all bits were set to 1).
> 
>     NOTE 1 - If [the basicConstraints] extension is not present, or is
>     flagged non-critical and is not recognized by a certificate-using
>     system, then the certificate is to be considered an end-entity
>     certificate and cannot be used to verify certificate signatures.
> 
> So, X.509 imposes a requirement for the basicConstraints extension to be 
> present in version 3 intermediate certificates, but it does not impose 
> such a requirement for any other extensions.  The language in section 6 
> of RFC 3280 is based on this.
> 
> Dave
> 
> Wen-Cheng Wang wrote:
>

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 20 Nov 2004 14:51:43 +0800

Dave,

It is quite natural for a profile to impose more strict recommendation, requirements
and security considerations that the standard it is based on.
Since the role of RFC 3280 is to be a profile of X.509, it is supposed to be more strict
than what X.509 imposes. Not only on the format of certificates and CRLs but also
on the validation algorithm. Therefore, I do not think "a certification path that would
be valid under X.509 is invalid under RFC 3280" is a problem. On the contrary, I do
think "a certification path that would be invalid under X.509 is valid under RFC
3280" will be a problem.

When designing the RFC 3280 path validation algorithm, PKIX WG should
not take "what X.509 says about this" as the only the factor of considerations.
Another more important factor is the scurity consideration. And if following
more strict scurity considerations, PKIX WG finally conclude that it is a flaw
in X.509, then PKIX WG should feed back a defect report to X.509
liaison.

Maybe I should not quote the text from RFC 3280 4.1.2.3, because it seems
that my quotation misled the direction of dicussion. Instead, I should mention
that the meaning of a v3 certificate without the keyUsage extension is not
clear. Both RFC 3280 and X.509 do not have clear interpretation about this.
That is my intention. Honestly, my current implementation of path validation
algorithm accepts v3 certificates without the keyUsage extension too, because
I want my implementation be faithful with respect to RFC 3280. However,
accepting v3 certificates without the keyUsage extension really make me
nervous because the implication is unclear. What if my path validation
implementation accept a certificate of which the subject public key is not
supposed to be used for verifying the signature on public key certificates?

There may be two kinds of interpretation for a v3 certificate without the
keyUsage extension:

The first one is what you mentioned:
   If the keyUsage extension is not present in a v3 certificate, then
   it would be the same as if the extension were present and all bits
   were set to 1. That is, no restrictions are imposed on the key usage
   of the certificate.

The second one is:
   If the keyUsage extension is not present in a v3 certificate, then
   it would be the same as if the extension were present and all bits
   were set to 0. That is, the key is intended for some purpose other
   than those listed in the KeyUsage type.

If we decide to adopt the first interpretation and are sure that
such interpretation will not cause any security problem, then I
will accept the current text of RFC 3280. However, if we decide
to choose the second interpretation, then obviously  the current
text of RFC 3280 needs to be changed.

Please note that X.509 (2000) 8.2.2.3 says:
   A bit set to zero indicates that the key is not intended for that purpose.
   If all bits are zero, it indicates the key is intended for some purpose
   other than those listed.
That implies if the second interpretation is adopted then by default a
v3 certificate without the keyUsage extension can not be used for
verifying the signature on public key certificates.

Therefore, I think we should try to make consensus on the
interpretation of a v3 certificate without the keyUsage extension
first, then we can decide whether the current text of RFC 3280
need to be changed.

Wen-Cheng Wang
  ----- Original Message ----- 
  From: David A. Cooper 
  To: Wen-Cheng Wang 
  Cc: pkix 
  Sent: Saturday, November 20, 2004 12:28 AM
  Subject: Re: 3280bis issue: checking keyCertSign bit in path validation

  There are many places in which RFC 3280 imposes requirements for the issuance of certificates that are not imposed by X.509.  But, RFC 3280 does not include corresponding checks in section 6 because RFC 3280 does not attempt to declare that a certificate (or certification path) that would be valid under X.509 is invalid simply because the certificate was not issued in accordance with the RFC 3280.

    1.. X.509 states that the certificate serial number is an integer;  RFC 3280 requires CAs to use only non-negative integers that are at most 20 octets long.

    2.. X.509 states that the basicConstraints extension may be critical or non-critical; RFC 3280 requires that the extension be critical in intermediate (CA) certificates.

  In the case of keyUsage,  RFC 3280 imposes the requirement that you quote below, X.509 does not.  If the keyUsage extension is not present in a certificate, then no restrictions are imposed on the use of the certificate (i.e., it would be the same as if the extension were present and all bits were set to 1).

  Note that keyUsage is different from basicConstraints, where there is both an issuing and validation requirement.  That is, a version 3 certificate with no basicConstraints extension is effectively the same as a version 3 certificate with a basicConstraints extension with cA=FALSE.  X.509 states:

    NOTE 1 - If [the basicConstraints] extension is not present, or is flagged non-critical and is not recognized by a certificate-using system, then the certificate is to be considered an end-entity certificate and cannot be used to verify certificate signatures.

  So, X.509 imposes a requirement for the basicConstraints extension to be present in version 3 intermediate certificates, but it does not impose such a requirement for any other extensions.  The language in section 6 of RFC 3280 is based on this.

  Dave

  Wen-Cheng Wang wrote:

The text says:

That means:

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 20 Nov 2004 16:59:57 +0800

Steve,

You are right. There are two kinds of requirements (some of
them are actually recommendations). One kind of requirements
are to be imposed on CAs. The purpose of this kind of
requirements is to enforce all conforming CAs to issue
certificates and CRLs of the common format and therefore
help to achieve interoperability. The other kind of requirements
are to be imposed on RPs. The purpose of this kind of
requirements is to make sure the RPs can handle
certificates and CRLs issued by conforming CAs and
enforce security of their path validation.

Obviously, requirements in section 6 are for RPs. However,
not all requirements in other sections are for CAs. There
are requirements/recommendations in section 4 and 5 for
makeing sure conforming RPs can handle certificates and
CRLs issued by conforming CAs.

I agree that it is a good idea to add a statement in RFC
3280bis to say that the RPs has no obligation to check
equirements/recommendations imposed on CAs. However,
we should be more careful about wording. A "SHOULD NOT"
might be too strong. The validation algorithms specified
in RFC 3280 are simply a "basic" algorithms. As you mentioned,
the RPs are allowed to impose more strict requirements.
I do not see why RFC 3280 should discourage this.

Actually, I had even seen at least one implementation of path
validation algorithm that not only enforces to check the existence
of all mandatory extension fields but also even enforces to
check the criticality falg of the extension. Although the implementor
might misinterpret RFC 3280 so to impose such strict verification,
I think it not harmful as long as the implementation would
not accept "a certification path that would be invalid under RFC
3280".

Base on your recommendation of adding a clarification
statement in RFC 3280bis, I think we can also further try to
clearly distinguish "requirements/recommendations to be
imposed on CAs" and "requirements/recommendations
to be imposed on RPs". In fact, the current text of RFC 3280
already try to distinguish them. As you can see, many
requirements/recommendations in section 4 and 5 are
begin with "Conforming CA MUST/SHOULD/MAY..." or
"Applications MUST/SHOULD/MAY...". However, some
of the requirements/recommendations in section 4 and 5
do not clearly specify the target (CAs or RPs) to be
imposed on.

For example, RFC 3280 4.1.2.3 mandate that "This extension
MUST appear in certificates that contain public keys that are
used to validate digital signatures on other public key
certificates or CRLs." It is not crystal clear whether this
is only a requirements for CAs to issuing certificates or it is
also a requirement for RPs to check the extension.

The source of the ambiguity comes from that RFC3280 has
two kinds of target audiences and sometimes it is not crystal
clear which kind of audience is the statement for. A way to
solve this ambiguity is to further separate each section for a
basic field or a extension field into two sub-sections, namely
"recommendations and requirements for issuers" and
 "recommendations and requirements for applications", and
then put requirements/recommendations for different targets
into different sub-sections.

Another even better way to solve this ambiguity is to split
RFC3280 into two documents. One document will keep the title
"PKIX Certificate and CRL Profiles" but its content be changed
to be a "pure" profile (i.e. it should only specify "recommendations
and requirements for issuers" to make sure conforming issuers
will issue certificates and CRLs of the common format specified
by PKIX. The other document might be titled "PKIX Certification
Path Processing" and it will contains "recommendations and
requirements for applications", including path/CRL validation
algorithms, to make sure the RPs can handle certificates and
CRLs issued by conforming CAs and enforce security of their
path validation. However, split RFC3280 into two documents is
a big change, 3280bis team might think this is out of scope.
But I hope them take this into consideration.

Wen-Cheng Wang

---

From: Tom Gindin <[email-masked]>
Date: Sun, 21 Nov 2004 23:12:20 -0500

David:

        Wasn't the absence of this particular requirement a contributing 
factor to a serious problem once (the one where a well-known piece of RP 
software let EE certificates act as intermediate CA's)?  Verification does 
not need to check every possible requirement in the profile, but this one 
is actually important to RP's.  Indeed, isn't this a slightly better check 
than basicConstraints, because a dedicated CRL signing certificate will 
have basicConstraints.CA true but won't have keyCertSign?

                Tom Gindin

"David A. Cooper" <[email-masked]>
Sent by: [email-masked]
11/19/2004 11:28 AM
 
        To:     Wen-Cheng Wang <[email-masked]>
        cc:     pkix <[email-masked]>
        Subject:        Re: 3280bis issue:  checking keyCertSign bit in 
path validation

This shows up in a number of places.  For example:
1.      X.509 states that the certificate serial number is an integer;  
RFC 3280 requires CAs to use only non-negative integers that are at most 
20 octets long.
2.      X.509 states that the basicConstraints extension may be critical 
or non-critical; RFC 3280 requires that the extension be critical in 
intermediate (CA) certificates.
In the case of keyUsage,  RFC 3280 imposes the requirement that you quote 
below, X.509 does not.  If the keyUsage extension is not present in a 
certificate, then no restrictions are imposed on the use of the 
certificate (i.e., it would be the same as if the extension were present 
and all bits were set to 1).

Note that keyUsage is different from basicConstraints, where there is both 
an issuing and validation requirement.  That is, a version 3 certificate 
with no basicConstraints extension is effectively the same as a version 3 
certificate with a basicConstraints extension with cA=FALSE.  X.509 
states:
NOTE 1 - If [the basicConstraints] extension is not present, or is flagged 
non-critical and is not recognized by a certificate-using system, then the 
certificate is to be considered an end-entity certificate and cannot be 
used to verify certificate signatures.
So, X.509 imposes a requirement for the basicConstraints extension to be 
present in version 3 intermediate certificates, but it does not impose 
such a requirement for any other extensions.  The language in section 6 of 
RFC 3280 is based on this.

Dave

Wen-Cheng Wang wrote:

The text says:

   If the version of the certificate is v3, verify that a key usage 
extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for 
v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang