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

From: David Cross <[email-masked]>
Date: Fri, 16 Feb 2001 07:25:49 -0800

I concur with the following interpretation - there is not good cause for
change to this interpretation:

->After some discussion, we decided that the path length constraint in basic

constraints was intended to specify the number of intermediate certificates 
that could follow this certificate. This meant the max_path_length did not 
apply to the end certificate.

Regards,

David B. Cross

David B. Cross
Program Manager 
.NET Security 
(sent using Windows XP and Office XP)

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]] 
Sent: Thursday, February 15, 2001 11:04 AM
To: Tim Polk
Cc: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Thanks for raising this issue for discussion, Tim. I have several concerns
with the pathLenConstraint semantics described in new-part1-04.

First, this is an incompatible change to the existing semantics. RFC 2459
clearly states that pathLenConstraint "gives the maximum number of CA
certificates that may follow this certificate in a certification path." The
X.509 specs include similar wording. Many certificates have been issued with
the current semantics and code has been written that implements these
semantics. We shouldn't change the semantics in an incompatible manner
unless we have a very good reason.

Second, you have not described a good reason for this change. In the example
that you presented, certificates issued by CA "B" are covered by an indirect
CRL from CA "C". B wants to vouch for C as a CA *and* a CRL issuer. To avoid
the problem with pathLenConstraint, B should issue two certificates for C: a
CA certificate and an end-entity certificate with the cRLSign keyUsage bit
set.

Third, this will change the basic meaning of validating a path (or a
certificate). With the 2459 semantics, a path is either valid or it's not.
With the looser revised semantics, a path may be valid except for the
keyCertSign keyUsage in the final certificate. This means that the result of
a DPV operation ("Is this cert valid?") will not be a boolean value. It will
be something more complicated ("Yes, but not for keyCertSign keyUsage"). I
oppose making such a basic change without a strong reason and I haven't
heard any strong reason.

Thanks,

Steve

Tim Polk wrote:
> 
> Folks,
> 
> As noted in the Last Call message, there is an open issue on Part 1 
> regarding the processing of path length constraints.  The basic 
> constraints text (4.2.1.10, page 37) and path validation algorithm 
> wrap-up procedure (6.1.5, page 73) contained in the current draft of 
> Part1 does not consider the path length constraint for an end 
> certificate.  This has sparked some controversy.
> 
> In this message, I will attempt to describe the issue and the 
> trade-offs between the two different interpretations.  I apologize in 
> advance for the length of this message.  Brevity is not my strong 
> suit.
> 
> We first ran into this issue at NIST when we were developing the X.509 
> path validation tests.  There was some debate among the participants 
> whether a path should be rejected if the max_path_length state 
> variable was less than or equal to zero and the end certificate was a 
> CA certificate (i.e., basicConstraints included cA=TRUE).
> 
> After some discussion, we decided that the path length constraint in 
> basic constraints was intended to specify the number of intermediate 
> certificates that could follow this certificate. This meant the 
> max_path_length did not apply to the end certificate. The current text 
> of part1 reflects this line of reasoning:
> 
>  From 4.2.1.10:
> 
>  >The pathLenConstraint field is meaningful only if cA is set to TRUE. 
> In this  >case, it gives the maximum number of CA certificates that 
> may follow this  >certificate in a certification path. (Note: One end- 
> entity certificate will  >follow the final CA certificate in the path. 
> The last certificate in a path  >is considered an end-entity 
> certificate, whether the subject of the  >certificate is a CA or not.)
> 
> 6.1.5 supports this interpretation through omission:  there is no 
> processing step to consider the value of  max_path_length in the 
> wrap-up-procedure.  (The comparison step appears in 6.1.4, 
> "Preparation for Certificate i+1" so it is already performed for every 
> other certificate in the path.)
> 
> 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.
> 
> new step:
>  >
>  >(h) If the certificate was not self-issued, verify that 
> max_path_length is  >greater than zero and decrement max_path_length 
> by 1.
> 
> comparison statement:
>  >
>  >If check (h) fails, the procedure terminates, returning a failure 
> indication  >and an appropriate reason.
> 
> What is less straightforward (at least to me) is which approach is the 
> appropriate one.
> 
> Essentially, the relying party wishes to trust the public key of a 
> subject to perform an action *other* than validating a signature on a 
> certificate.  During the preparation for this certificate the value of 
> max_path_length has been decremented or reset to zero (steps (l) or 
> (m) in
> 6.1.4) , indicating no additional CA certificates may be processed.
> 
> 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?
> 
> I cannot come up with a security rationale for rejecting such a 
> certificate.  On the other hand, I do need to stretch a bit to devise 
> a scenario where accepting this certificate is beneficial.
> 
> Here is the beneficial scenario:
> 
> CA "A" issues a CA certificate to CA "B".  "A" trusts end entity 
> certificates issued by "B", but does not trust "B" to issue 
> certificates to other CAs.  "A" includes basic constraints in the 
> certificate it issues to "B" with cA = TRUE and pathLen = 0.
> 
> "B" does not issue its own CRLs, but delegates this to CA "C".  "B" 
> also trusts "C" to issue end entity certificates. So, "B" includes 
> basic constraints in the certificate it issues to "B" with cA = TRUE.
> 
> Alice's trust point is "A".
> Bob's trust point is "B", and "B" issued his certificate.  Bob's 
> certificate includes a CRL distribution points extension identifying 
> "C" as the indirect CRL issuer. Carol's trust point is "C", and "C" 
> issued her certificate.
> 
> Using the current text/algorithm, Alice can validate the certification 
> path for Bob including the indirect CRL signed by "C".  This required 
> Alice to validate the certification path ending with the certificated 
> issued by "B" to "C".
> 
> Alice cannot validate Carol's certificate, though.  Alice cannot trust 
> any certification path  that includes the certificate issued by "B" to 
> "C" as an intermediate certificate.
> 
> This *seems* to satisfy the spirit of the path length constraint, but 
> not the letter.
> 
> On the other hand:
> 
> If max_path_length is used to reject end certificates whose subjects 
> are CAs, Alice would not be able to validate Bob's certification path.  
> Alice could not process the indirect CRL.
> 
> If "A" relaxed the path length constraint (1 instead of zero) Alice 
> would be able to validate Bob's certification path.  Unfortunately, 
> this would also permit Alice to validate Carol's certification path, 
> which "A" did not intend.
> 
> This honors the letter of the path length constraint but did not 
> achieve the intended results.
> 
> Even with this scenario, there are at least two workarounds.  Either 
> CA "A" or CA "B" could issue a certificate to "C" that omitted the 
> basic constraints extension (but included the cRLSign bit in 
> keyUsage).  Alice would then be able to process paths as intended.  
> Alice would accept Bob's certification path and reject Carol's.
> 
> -----------------------------------
> 
> In summary:
> 
> (1) The current text describes a comparatively liberal interpretation 
> of basic constraints.
> (2) A straightforward reading of RFC 2459 or X.509 implies a more 
> conservative interpretation.
> (3) Either interpretation may be easily accommodated in the new 
> specification.
> (4) I cannot devise a security attack based on the more liberal
interpretation.
> (5) I can devise one scenario where the more liberal interpretation was
> beneficial. (It is unclear if there are others.)
> (6) It is certainly possible to implement this same scenario with the more
> conservative interpretation.  It requires issuing one additional
certificate.
> 
> Any thoughts?
> 
> Thanks,
> 
> Tim Polk
> 
> P.S.  I should state that implementations exist that implement both 
> interpretations.

---

From: "Linn, John" <[email-masked]>
Date: Wed, 21 Feb 2001 08:57:05 -0500

I share Steve's caution here.  The original text corresponds to that in
X.509; in the interests of convergence between profiles, I'd recommend that
the PKIX profile avoid making a divergent change to the semantics of
pathLenConstraint unless the current semantics are unworkably defective.
This doesn't seem to be the case here. Further, revisiting the definition of
which certificates are EE vs. CA at this point in the process seems like the
sort of change that might propagate unexpected implications or
inconsistencies in other areas of certificate processing; I'm not sure that
we should take this risk unless the need is compelling.

--jl

> Sent: Friday, February 16, 2001 5:24 PM
> To: David A. Cooper
> Cc: [email-masked]
> "David A. Cooper" wrote:
> > I believe that the problem we are currently experiencing is as a
> > result of the original text not being sufficiently clear.
> 
> I thought the original text was quite clear. But I guess not.
> 
> The original text said:
> 
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow 
> in the path.
> 
> The revised text says:
> 
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. (Note: One end-
>    entity certificate will follow the final CA certificate in 
> the path.
>    The last certificate in a path is considered an end-entity
>    certificate, whether the subject of the certificate is a 
> CA or not.)
>    A pathLenConstrinat of zero indicates that only an end-entity
>    certificate may follow in the path.
> 
> I find it odd to say that a certificate with cA=TRUE is a CA 
> certificate
> *unless* it is the last certificate in a path. I suppose this 
> is only a
> wording problem, but I find this wording *less* clear than the old
> wording.
> 
> I also question whether the revised semantics for 
> pathLenConstraint will
> be as easy to understand for CA operators.
> 
> Do we really need to complicate things like this to handle a case that
> you admit will be rare (a CA that uses another CA for indirect CRLs,
> combined with max_path_length of 0)?
> 
> > You seem to suggest that we are now stating that a path may be valid
> > expect for the keyCertSign key usage. However, one should never make
> > use of the keyCertSign key usage bit when it appears in the last
> > certificate in a path.
> 
> This is true. But I doubt that it's widely understood. 
> Perhaps it should
> be highlighted in the document.
> 
> > Of course, as I mentioned earlier, it is possible to achieve the
> > desired results in a PKI using either of the semantics, so the main
> > goal should be to ensure that whatever the final decision is, the
> > semantics are clearly written in the next draft of the 
> certificate and
> > CRL profile.
> 
> Agreed.
> 
> > Perhaps others, particularly those who have already implemented this
> > extension, could provide their opinions on this subject as well.
> 
> I agree with this as well. I'll be on vacation next week, but I trust
> you folks to make the right decision. If I'm alone in my concern about
> this, then we should go with rough consensus, which seems to 
> be running
> against me at the moment.
> 
> -Steve
>

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 28 Feb 2001 16:25:35 -0500

David, absolutely agree about the alignment (we need to at least have
alignment of the resolution of the defect, however it is possible of course
for the words to differ in 509 and in PKIX as long as the meanings are
aligned).

From the 509 perspective, we'd like to submit the new defects for the formal
ISO ballot process within the next couple of weeks and I want to be sure
that the text we send for ballot is as close to the 'final approved' text as
possible. Alignment is of course of very high importance, so the outcome of
this PKIX discussion will be very valuable. I think we're all on the same
page with respect to intent. In my mind, in the case where the final cert in
a path is a cert that with a subject that is a CA, for purposes of
validation of such a path the CA is acting in the role of an end-entity.
That's probably why I'm not so concerned about the use of the terms.
However, if there are better words to explain that we can certainly modify
the text before the ISO ballot (its MUCH easier to change before the ballot
than as a result of a ballot). I only want to change it once though so I'll
wait a bit to see the outcome of this discussion (and of course any change
would also have to go through the OSIDirectory list, for those who are not
also on the PKIX list to get to review it). 

I hope PKIX folks are also looking at DR 273-277 posted on the Bull server.
They're all X.509 defects as well and I want to be sure they've gotten the
full review they need before ballot.

Cheers
Sharon 

> From: David A. Cooper [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 2:33 PM
> To: [email-masked]
> Steve,
> Last week Hoyt Kesterson sent a message to the PKIX list 
> pointing out some defect reports against X.509. One of these, 
> DR 272, deals with path length constraints:
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRep
> orts/X.509andRelated/DR_272Rev1.pdf
> 
> DR 272 proposes adding some new text to X.509 to help clarify 
> the meaning of path length constraints in public key and 
> attribute certificates. From my reading of the text, there 
> seems to be an assumption that every certification path will 
> end with an end-entity certificate as in the following sentence:
> 
>                  The constraint controls the number of non 
> self-issued CA certificates between
>                  the CA certificate containing the constraint 
> and the end-entity certificate.
> 
> Hoyt's message states that DR 272 has not yet been submitted 
> for formal voting, but that it will be soon. We should keep 
> this in mind when deciding on the text to use in new-part1 so 
> we can ensure that X.509 and new-part1 are both clear and 
> consistent in this area.
> 
> Dave
> 
> At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
> >I have not seen anything approaching rough consensus on the basic
> >question of which of these semantics we should use. John 
> Linn and I have
> >sent email favoring the RFC 2459 semantics 
> (pathLenConstraint being the
> >maximum number of subsequent CA certificates allowed). You and David
> >Cross have sent email favoring the new-part1 semantics
> >(pathLenConstraint being the maximum number of intermediate 
> certificates
> >allowed). If there is no further discussion on the list, we 
> may need to
> >check consensus in Minneapolis.
> 
>