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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,
 
> It is certainly true that specifying name constraints for trust anchors
> will work when a single trust anchor is used. Perhaps the sentence in
> section 6.2 should be changed to say "Implementations may also augment
> the algorithm presented in section 6.1 to further limit the set of valid
> paths which begin with a particular trust anchor."
> 
> 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.2 says " The path validation algorithm describes the process of
validating a single certification path".

Currently, the text for section 6.1. is for a single anchor while the text
for section 6.2 is for more than one 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."

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. 

Denis 

> -Steve
> 
> Denis Pinkas wrote:
> >
> > One topic per message: This one about applying constraints to the path
> > validation algorithm.
> >
> > In section 6.2 we now have:
> >
> >    The path validation algorithm describes the process of validating a
> >    single certification path.  While each path begins with a specific
> >    trust anchor, there is no requirement that all paths validated by a
> >    particular system share a single trust anchor.  An implementation
> >    that supports multiple trust anchors may augment the algorithm
> >    prresented in section 6.1 to further limit the set of valid paths
> >
> > ...Please a single r for prresented.
> >
> >    which begin with a particular trust anchor.  For example, an
> >    implementation may specify name constraints that apply to a specific
> >    trust anchor.
> >
> > While the sentence is true in the case of multiple trust anchors it is as
> > well valid for a single one. So a similar sentence is needed in section 6.1.
> >
> > In section 6.1 the text says:
> >
> >    A particular certification path may not, however, be appropriate for
> >    all applications.  The path validation process also determines the
> >    set of certificate policies that are valid for this path, based on
> >    the certificate policies extension, policy mapping extension, policy
> >    constraints extension, and inhibit any-policy extension.
> >
> > The text should rather say:
> >
> >    An application may augment the algorithm presented in section 6.1
> >    to further limit the set of valid paths. For example, an
> >    implementation may specify additional constraints like name
> >    constraints or specific extensions that apply to the application.
> >    Therefor the conditions which are described in this section are
> >    minimum conditions. The path validation process described in this
> >    section determines the minimum conditions that are to be fulfilled
> >    by the certification path for the set of certificate policies
> >    that are valid for this path, based on the certificate policies
> >    extension, policy mapping extension, policy constraints extension,
> >    and inhibit any-policy extension, as well as for the name
> >    constraints, if any.
> >
> > The main difference between 6.1 and 6.2 is that the additional contraints
> > (policy or name constraints) apply globally to the path validation algorithm
> > when there is one trust anchor (6.1), but may apply on every trust anchor
> > where there are multiple trust anchors (6.2).
> >
> > Denis