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
----------------------------------------------------------------
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
-----Original Message-----
From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx]
Sent: Tuesday, August 21, 2001 3:03 PM
To: Peter Hesse
Cc: wford@xxxxxxxxxxxx; wpolk@xxxxxxxx; dsolo@xxxxxxxxxxxx;
ietf-pkix@xxxxxxx; iesg@xxxxxxxx
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
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