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

From: "Housley, Russ" <[email-masked]>
Date: Tue, 21 Aug 2001 16:54:22 -0400

Peter:

Thanks for providing the context for your comments.  Tim Polk is on 
vacation this week.  I will get with him when he returns, and add some 
clarifying editorial text.

Russ

At 04:32 PM 8/21/2001 -0400, Peter Hesse wrote:

>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:[email-masked]>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:
>
>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: Hiroyuki Sakakibara <[email-masked]>
Date: Wed, 22 Aug 2001 14:50:44 +0900

Hello. I have a comment related to path validation with a self-signed
certificate.

I think that in 6.1  Basic Path Validation, it is not clear that whether
self-signed
NON trust certificates may be included in a path or not.
(namely intermediate self-signed certs, not oldWithNew, newWithOld)

Plese note that I am not talking about a self-signed certificate to begin a
path,
talking about self-signed certificates in the middle of a path.

For example,

CA1 cross certifies with BridgeCA
CA2 cross certifies with BridgeCA
CA2 issues Cert_EE.(EndEntity cert)
SelfSignedCert_CA1 is trust anchor.
BridgeCA has a selfsigned certificate(SelfSignedCert_BridgeCA).

Based on the relation ship between issuer and subject or AKI/SKI,
the following 2 paths would be constructed.

(1) SelfSignedCert_CA1 -> CrossCert_CA1toBridgeCA
     ->  CrossCert_BridgeCAtoCA2 -> Cert_EE

(2) SelfSigned_CA1 -> CrossCert_CA1toBridgeCA
    ->  SelfSignedCert_BridgeCA -> CrossCert_BridgeCAtoCA2 -> Cert_EE

I suppose that most validation softwares implement (1), simple one,
and it could be a minimum requirement for interoperability.

In case of  (2), there is an advantage that a validation software could
check
the status of SelfSignedCert_BridgeCA, shown in the appendix below.

So, I think that it should be clear that intermediate self-signed
certificates may be
included(optionally), or ignored,  in the document.
I think that (1) is mandatory, and (2) is optional(not inhibited).

Folks, what do you think about this issue ?

* About ISO/IEC 9594-8

According to current ISO/IEC 9594-8 document, in 8.1.5 Self-Issued
certificates
it seems that intermediate self-signed certificates shall be ignored in path
construction/validation.
However, considering  the advantage of checking intermediate self-signed
certificates shown below,
 I don't understand why they "shall be ignored",
because checking them would be meaningful from the point of view of
security.

I think that investigation of intermediate self-signed ceritificates may be
optional,
should not inhibited, so, "may be ignored" would be better.

This is not a mailing list for 9594-8, however RFC2459 related documents are
based on
9594-8, so, I will also send my opinioin about it.

-------------------- Advantage of  validation of path
(2) --------------------

If a validation software implements (2),
the software could check the validity status of SelfSignedCert_BridgeCA.

Assume that CA1 issues a cross certificate whose
notAfter excess notAfter of self-signed certificate of BridgeCA.

such as
notAfter of SelfSignedCert_BridgeCA is "2001/12/31"
notAfter of CrossCert_CA1toBridgeCA  is "2002/12/31" .

when BridgeCA inhibits such cross certificate, it will be an invalid
cross-certificate.

Useally, BridgeCA checks a cross-certificate from CA1 when issuance,
however, if CA1 is a rough CA, or a bug CA(including mis-operations),
after issuance of a valid cross certificate,
CA1 could issue an additional invalid certificate and distribute it to LDAP
etc...
without BrigeCA's permission .

( In this case, for a RP, CA1 is a trust anchor, so, CA1 must not be a rough
CA, however, this kind of rough operation would happen in another example.
for example,

CA1(has self-signed cert, trust anchor) -> CA2(has self-signed cert) -> CA3
-> CA4( has self-signed cert)  -> EE

CA3 issues an invalid cross certificate to CA4.
In this example, a trust anchor CA1 behaves properly, however,
CA3 does rough operations. )

RP could check the revocation status of Cert_BridgeCASelfsigned also.

This kind of problem would happen in a multi CA products environment.

To avoid this problem, interoperability test, operation, management
among multi CA products should be done well,
or a RP should check the status of intermediate self-signed certificates,
or a CA which cross-certifies with other CAs should observe behavior of
other CAs, etc...?

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]