[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Denis:

I agree with Steve Hanna's observation. However, I think that we can include a bit of notice in section 6.1. I propose the following replacement paragraph:

   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.  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.  To achieve this, the path
   validation algorithm constructs a valid policy tree.  If the set of
   certificate policies that are valid for this path is not empty, then
   the result will be a valid policy tree of depth n, otherwise the
   result will be a null valid policy tree.

I suggest that we replace the first paragraph of section 6.2. with:

   The path validation algorithm describes the process of validating a
   single certification path.  While each certification path begins with
   a specific trust anchor, there is no requirement that all
   certification paths validated by a particular system share 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 certification paths which begin with a particular
   trust anchor.  For example, an implementation MAY modify the
   algorithm to apply name constraints to a specific trust anchor during
   the initialization phase, or the application MAY require the presence
   of a particular alternative name form in the end entity certificate,
   or the application MAY impose requirements on application-specific
   extensions.  Thus, the path validation algorithm presented in section
   6.1 defines the minimum conditions for a path to be considered valid.

Russ


At 05:45 PM 4/19/2001 +0200, 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