Re: Recommended changes to draft-ietf-pkix-new-part1-08

[Steve Hanna <steve.hanna@xxxxxxx>]

The current document seems clear to me, but I've been working with it
for years! ;-) Making it clearer is certainly a good idea and I support
these changes. I believe they fall into the category of minor editorial
changes to clarify the meaning already present in the document and
agreed to by the working group. Therefore, I don't think there should be
any problem with making these changes, even at this late date.

Let me make a few minor comments and offer some specific text for the
first change so we have something specific to discuss.

> Peter Hesse wrote:
> --------------------------------------------------------------------------
> 
>    To meet this goal, the path validation process verifies, among
> other
>    things, that a prospective certification path (a sequence of n
>    certificates) satisfies the following conditions:
> 
>       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> 
>       the issuer of certificate x+1;
> 
>       (b)  certificate 1 is issued by the trust anchor;
> 
>       (c)  certificate n is the certificate to be validated; and
> 
>       (d)  for all x in {1, ..., n}, the certificate was valid at the
>       time in question.
> --------------------------------------------------------------------------
> 
> In my opinion, (b) should be changed to explicity specify that
> certificate 1 is not a self-signed certificate issued by the trust
> anchor.

Actually, certificate 1 *could* be the self-signed certificate if for
some reason the path actually happened to start with that certificate.
That would be unusual, but I do not think we should explicitly forbid
it. But I agree that it would be good to supply explicit guidance at
this point in the document that the trust anchor should not normally be
included in the path validation procedure.

In order to have a specific textual change to discuss, I'll suggest that
immediately following point (d) above, a sentence (a new paragraph, I
suppose) be added that says:

   When the trust anchor is provided in the form of a self-signed
   certificate, this certificate is not included as a part of the
   prospective certification path.

> The second change is needed because the logic of section 6.1 does not
> specifically say what certificates are subject to the validation
> processing other than the part quoted above.

Actually, section 6.1 says "Step (2) is performed for all certificates
in the path." Step (2) is defined elsewhere as Basic Certificate
Processing, which is discussed in section 6.1.3. And, in the section you
quoted above, it defines the "prospective certification path"  as "a
sequence of n certificates".

But I still think that your suggestion below is a good one. It's useful
to say the same thing two or three times to make sure there's no
misunderstanding, especially since this is a change from RFC 2459, where
the trust anchor *was* included in the path for validation purposes.

>  My second recommendation
> is to change the beginning of 6.1.3 to the following:
> 
> --------------------------------------------------------------------------
> 
> The basic path processing actions to be performed for certificate i
> (for all i in [1...n]) are listed below.
> --------------------------------------------------------------------------
> 
> These changes would allow certainty that
> - certificate 1 is not the self-signed trust anchor certificate
> - only certificates 1...n are processed, therefore explicitly not
> processing a self-signed trust anchor certificate if one exists in the
> path.
> 
> Again, apologies for bringing this up so late, but I feel this issue
> is quite important for interoperability between path validation
> implementations.

Thanks for bringing it up. It's good to make the document clearer. I
just hope we don't descend into a long debate now...

Steve Hanna
Sun Microsystems, Inc.