Ahh, thank you for the detailed response...and I think I see where our differences arise.
Referring back to the description that Tim gave us,
"If that subject of the last certificate is not a CA, the path is clearly acceptable. But what if the subject is a CA? Should the relying party reject the path because the key is in a CA certificate *or* accept the path because the subject is not being treated as a CA?"
There is a more fundamental issue here. It appears that you are proposing a certificate with a Key Usage extension, but without keyCertSign=1. Is this a valid CA certificate? I assert that it is not.
From the PKIX profile for basicConstraints:
"This extension MUST appear as a critical extension in all CA certificates."
Since the PKIX profile is silent on this next point, from the Minimum Interoperability Specification for PKI Components (MISPC):
"CA certificates shall contain a basicConstraints extension with the cA component set to TRUE."
Then, reusing you're own quote,
"If the cA bit is asserted, then the keyCertSign bit in the key usage extension MUST also be asserted."
Summarizing, if we're referring to a CA certificate, then:
1. It must include a basicConstraints extension;
2. cA=TRUE (if not set to TRUE, then I assert that the subject is an
end entity regardless of the subject DN);
3. It must include a basicConstraints extension
4. keyCertSign=1
Thus, all CA certificates will always have keyCertSign=1. Otherwise, it is not a CA certificate, regardless of the subject DN.
Furthermore, from the basicConstraints profile,
"[pathLenConstraint] gives the maximum number of CA certificates that may follow this certificate in a certification path."
Thus, if pathLenConstraint=0, then no certificates with cA=TRUE may follow; if pathLenConstrain=1, then at most one certificate with cA=TRUE may follow, and so on.
Then, I agree with Tim's proposal:
"If the working group disagrees with this interpretation, the changes
to
Part 1 are straightforward. First, modify the parenthetical in
4.2.1.10 to
indicate that the end certificate in the path is considered a CA
certificate if the basic constraints extension indicates
cA=TRUE. Secondly, add one new step (h) to 6.1.5 and reject the
certification path if (h) fails."
I agree with these statements because, by definition, any entity which is a CA can issue certificates. I also suggest adding the statement as quoted above from the MISPC to Section 4.2.1.10. Otherwise you end up with the scenario that started this whole discussion.
Per the Microsoft implementation, have you confirmed that the path length constraint variable is actually being processed?
Dave S.
"David A. Cooper" wrote:
At 03:44 PM 3/2/01 -0500, David Simonetti wrote:--David,You write, "With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems."
I think, more specifically, the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1.
David,Consider the following scenarios:
scenario 1:
CA1 ----------------------------> CA2 ----------------------------------> CA3
basicConstraints:keyUsage: cA=TRUE cRLSign pathLenConstraint=0 keyUsage: CRLDistributionPoints: keyCertSign, cRLSign cRLIssuer: CA3 scenario 2:
CA1 ----------------------------> CA2 ----------------------------------> CA3
basicConstraints:basicConstraints: cA=TRUE cA=TRUE pathLenConstraint=0 keyUsage: keyUsage: keyCertSign, cRLSign keyCertSign, cRLSign
CRLDistributionPoints: cRLIssuer: CA3 In both scenarios, CA1 wishes to allow its relying parties to validate certificates issued by CA2. Also, in both scenarios, CA2 does not issue its own CRLs, but instead relies CA3 to issue CRLs on its behalf. The only difference is that in scenario 1 the certificate issued by CA2 to CA3 only "authorizes" CA3 to sign CRLs, whereas in scenario 2 the certificate issued by CA 2 to CA3 "authorizes" CA3 to sign both certificates and CRLs (perhaps CA2 wishes to allow its own relying parties to accept certificates issued by CA3).
In scenario 1, since CA2 is not "authorizing" CA3 to sign certificates, it does not include the basicConstraints extension in the certificate it issues to CA3. In scenario 2, basicConstraints is included as required since the intention is to "authorize" CA3 to sign certificates.
No matter how pathLenConstraint is defined, CA1's relying parties will be able to validate CRLs issued by CA3 in scenario 1. With scenario 2, however, with one definition relying parties will be able to validate the CRLs, but with the other they will not due to the presence of basicConstraints in the certificate issued by CA2 to CA3.
Note that what you suggest ("the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1") would not work. Using the definition of pathLenConstraint that you support, such a certificate would be rejected as a "CA-certificate" since it contains basicConstraints with cA=TRUE. This is also contradictory to the PKIX profile:
The cA bit indicates if the certified public key may be used to verify signatures on other certificates. If the cA bit is asserted, then the keyCertSign bit in the key usage extension MUST also be asserted. If the cA bit is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted.
With the new semantics, if the keyUsage extension is absent, is it then possible for the CRL-issuer, assuming it is a CA, to also sign certificates?
Two points:1) As noted in the quote above, if one does not wish to allow a certificate subject's public key to be used to verify certificates, then one should not include basicConstraints with cA=TRUE. If it is included then the issuing CA intended to allow the subject to sign certificates. On the other hand, it we are dealing with a scenario such as scenario 2 above, then it would always be the case that CA1's relying parties would not accept certificates signed by CA3 (even if they accept CRLs signed by CA3). If CA1's relying parties tried to accept a certificate signed by CA3 then they would do so by attempting to validate a path of the form CA1--->CA2--->CA3--->EE and this path would fail as a result of the path length constraint.
2) As I stated in my previous message, nobody is proposing new semantics. We are merely trying to deal with the results of previously ambiguous text. The semantics that I have been advocating have already in implemented in products. For example, I used the NIST X.509 certification path test suite to test the path validation code in Outlook Express on a Windows 98SE machine, and for the path length tests, the results of validation were the same whether the last certificate in the path included basicConstraints with cA=TRUE or not. So it seems that Microsoft's path validation code currently implements the semantics that I have been advocating. In addition, if you look at DR 272, which is designed to clarify the meaning of path length constraints in X.509, the text seems to suggest that it has always been the ISO Directory group's intention that pathLenConstraint be interpreted in this way.
So, if we decide that pathLenConstraints should be calculated differently when the last certificate in the path includes basicConstraints with cA=TRUE, then we will be "breaking" real, deployed implementations. We would also need to work to see that DR 272 is changed so that X.509 is consistent. It may be the case that there are also deployed implementations that compute pathLenConstraints differently when the end certificate included basicConstraints with cA=TRUE that would be "broken" if we agree to go the other way. But even if this is the case, we should not reject the idea of computing pathLenConstraint the same way for all paths of equal length based on the argument that this would be defining "new semantics". If there had been agreement in past on what the "old semantics" were, then we wouldn't even be talking about path length constraints now.
Dave