Re: Open Issue in Part1: path length constraints

["David A. Cooper" <david.cooper@xxxxxxxx>]

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