Subject: Re: Open Issue in Part1: path length constraints

From: [email-masked]
Date: Thu, 1 Mar 2001 14:27:03 -0500

But why would you care about a CA's signature on an OCSP response or a CRL
if you don't trust the signature on the EE certificate you're inquiring
about?

I think that the alternative semantics under discussion can cause a real
difference in behavior only if the CA is using its certificate-signing key
for something that's not certificate-related at all - OCSP, CRL and CPS
signatures are all uninteresting except in the context of an
otherwise-trusted certificate signed by the CA.

John

Marc Branchaud <[email-masked]>@home.x509.com on 03/01/2001 12:53:15 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Open Issue in Part1: path length constraints

Bob Jueneman wrote:
>
> I would agree with David, that using the same key or certificate
> for both correspondence and certificate issuance would be
> extremely improbable.

How about a CA key signing OCSP responses?  Or CRLs, for that matter.
Either
are non-certificate "messages".

          Marc

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 01 Mar 2001 15:12:33 -0500

>if you don't trust the signature on the EE certificate you're inquiring

It will not always be the case that an CRL or OCSP response will be signed by the same entity (e.g, CA) that signed the EE certificate of interest. It may be that a certificate is issued with a cRLDistributionPoints extension specifying that corresponding CRLs will be issued by a different entity. The issuer of the CRLs does not have to be a CA (i.e., the certificate issued to this entity is not required to contain the basicConstraints extension). So, it is possible that a relying party will accept CRLs issued by some entity even though it would not accept certificates issued by this entity.

Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints. With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems.

>otherwise-trusted certificate signed by the CA.

I disagree. The only disagreement we have occurs when a path length constraint has been imposed and the final certificate in the path includes a basicConstraints extension with cA=TRUE. According to PKIX, the cA component of basicConstraints is only used to specify whether the certificate subject is trusted to sign certificates. The value of basicConstraints says nothing about whether the certificate subject is trusted to issue CRLs, OCSP responses or anything else other than certificates.

I would also like to note again that the current discussion is not about whether the interpretation of path length constraints should be changed. The text in RFC 2459 was not sufficiently clear and as a result there are currently some implementations that follow one set of semantics and other implementations that follow the other set.

We need to make sure that new-part1 is clear about the semantics of path length constraint. However, given that both of the possible semantics have already been implemented, we can not really make a decision on the basis that one alternative describes the "current" semantics while the other represents a "change in the semantics".

Dave

---

From: David Simonetti <[email-masked]>
Date: Fri, 02 Mar 2001 15:44:46 -0500

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.  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?

Dave S.

"David A. Cooper" wrote:

> Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints.
>

--
David Simonetti
Securify (www.securify.com), 410-356-2260

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 02 Mar 2001 17:29:48 -0500

At 03:44 PM 3/2/01 -0500, David Simonetti wrote:
>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

---

From: David Simonetti <[email-masked]>
Date: Mon, 05 Mar 2001 16:19:03 -0500

David,

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:

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,

scenario 1:

CA1 ----------------------------> CA2 ---------------------------------->
CA3

basicConstraints:keyUsage:

cA=TRUEcRLSign

pathLenConstraint=0

keyUsage:CRLDistributionPoints:

keyCertSign, cRLSigncRLIssuer:
CA3

scenario 2:

CA1 ----------------------------> CA2 ---------------------------------->
CA3

basicConstraints:basicConstraints:

cA=TRUEcA=TRUE

pathLenConstraint=0

keyUsage:keyUsage:

keyCertSign, cRLSignkeyCertSign,
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

--

David Simonetti