Re: Open Issue in Part1: path length constraints

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

At 02:27 PM 3/1/01 -0500, John_Wray@xxxxxxxx wrote:
>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?

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.

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

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