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

From: "Housley, Russ" <[email-masked]>
Date: Tue, 21 Aug 2001 15:02:49 -0400

Peter:

I am not sure that I agree with your points, but maybe I do not fully 
understand your points.

Regarding the first change, I believe that we must allow the first 
certificate to be self-issued.  How else can key roll over at a root 
authority be accomplished.  Several documents describe the 
old-signed-with-new and new-signed-with-old approach.  And, the certificate 
path validation algorithm includes several feature just to accommodate this 
key rollover technique.

Regarding the second change, I think that section 6.1 provides the 
context.  There is even a ASCII-art flow chart in Figure 2.  I think that 
the text that goes with Figure 2 covers your point.  It says: "Step (2) is 
performed for all certificates in the path."  However, if other people 
think that a working change would make this point more clear, I am willing 
to make an editorial change.  The whole point is to communicate as clearly 
as possible.

Russ

At 10:24 AM 8/21/2001 -0400, Peter Hesse wrote:

>All,
>
>I realize these comments are coming quite late in the process, and I hope 
>not to cause too much of a problem.  However, I feel that standards need 
>to be quite explicit in certain areas, and the current draft of the 
>Internet X.509 Public Key Infrastructure Certificate and CRL Profile (son 
>of 2459) is still a bit ambiguous when it comes to processing self-signed 
>trust anchor certificates.  I propose two changes in order to reduce this 
>ambiguity.  First I will quote from the current draft, section 6.1:
>
>--------------------------------------------------------------------------
>    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.
>
>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.  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.
>
>--Peter
>
>----------------------------------------------------------------
>  Peter M. Hesse            CygnaCom Solutions, a division of
>  Phone: 703-270-3523                   Entrust
>  ICQ:   1942828                 Securing the Internet
>----------------------------------------------------------------
>"Pay no attention to what the critics say; there has never been
>a statue set up in honor of a critic." --Jean Sibelius

---

From: Peter Hesse <[email-masked]>
Date: Tue, 21 Aug 2001 16:32:44 -0400

Russ,

I agree with the fact that we must allow self-issued certificates to begin
the path.  However, I was saying self-signed, by which I meant "signed by
the private key that goes with the public key in the certificate".  I'm not
sure if there is a need to have the self-signed certificate in the path, but
I agree with Steve's point that we don't need to forbid it, we should
recommend against it.

The idea with my second point was to let validation systems know that "all
certificates in the path" did not necessarily include the self-signed
trusted root certificate.

The reason this all came up is that during the Bridge CA Phase II
demonstration, we had a PKI that was supposed to issue a name constraint in
their certificate issued to the Bridge, to limit the namespace for their
relying parties.  They placed this name constraint in their self-signed
certificate instead of the cross-certificate.  Their clients were all fine
with this processing, but when another party tried to validate the same path
using a different algorithm (that ignored the self-signed certificate
extensions) a different result was obtained.   It is this lack of
interoperability that I am striving to avoid with a little more
clarification text.

If I need to be clearer please let me know and I'll try.

--Peter

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 3:03 PM
To: Peter Hesse
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08

Peter:

Russ