Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,

> > > However, I object to adding support for limits on trust anchors to
> > > section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
> > > everyone MUST implement. Section 6.2 describes various ways to extend
> > > that algorithm. Multiple trust anchors is one. Limits on trust anchors
> > > is a second. PEM compatible processing is a third. If one argues that
> > > limits on trust anchors should be described in section 6.1, one could
> > > equally argue that PEM compatible processing should be described in
> > > section 6.1.
> >
> > I agree with the intent, but this is NOT what the text says. :-(
> >
> > In particular section 6.1 only says " This text describes an algorithm for
> > X.509 path processing". It does not qualifies it as basic nor says that it
> > is a set of minimum conditions.
> 
> Section 6 (third paragraph) says "In section 6.1, the text describes
> basic path validation." 

OK. One point for you for the use of the word "basic", but ...

one point for me because the text does not say that it is a set of minimum
conditions. :-)

> A few paragraphs later, it says "Section 6.2
> describes methods for using the path validation algorithm in specific
> implementations. Two specific cases are discussed: the case where paths
> may begin with one of several trusted CAs; and where compatibility with
> the PEM architecture is required."
 
> Section 6.1 (first paragraph) says "A conformant implementation MUST
> include an X.509 path processing procedure that is functionally
> equivalent to the external behavior of this algorithm." And section 6.1
> is titled "Basic Path Validation", while section 6.2 is titled "Using
> the Path Validation Algorithm".
 
> That's why I said that section 6.1 is the "basic" algorithm that
> everyone MUST implement and section 6.2 describes various ways to extend
> that algorithm.

 .. but the text does not say that it is a set of minimum conditions.
 
> > Section 6.2 says " The path validation algorithm describes the process of
> > validating a single certification path".

.. but the text frpom section 6.1. does not say that other constraints may
be applied even when there is a single trust anchor.

> > "An implementation that supports multiple trust anchors may augment the
> > algorithm presented in section 6.1 to further limit the set of valid paths
> > which begin with a particular trust anchor."
 
> This is one of several variations included in section 6.2. PEM
> compatible processing is also included in section 6.2. Section 6.2 is
> clearly not limited to variations which employ multiple trust anchors.

The only other case is PEM:

   It is also possible to specify an extended version of the above
   certification path processing procedure which results in default
   behavior identical to the rules of PEM [RFC 1422]. 

> > You are proposing that the text from section 6.1 describes the "basic"
> > algorithm, while the text from section 6.2. describes enhancements to the
> > basic algorihm. I would not be opposed to your proposal, ... but many text
> > changes would be required.
 
> I don't think so. I think the text at the start of section 6 is clear.
> Perhaps an introductory paragraph at the start of section 6.2 would make
> it even clearer, but I don't see any other changes that would be
> required.

The case of a single anchor with additional constraints is still not covered
by the current text.

Regards,

Denis
 
> -Steve