Subject: Path validation and self-signed certificates (was RE: Recommended changes to draft-ietf-pkix-new-part1-08)

From: Peter Hesse <[email-masked]>
Date: Wed, 22 Aug 2001 09:46:25 -0400

Hiroyuki,

I will attempt to discuss a few of these issues inline.

> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 1:51 AM
> To: Housley, Russ; Peter Hesse
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
> 
> 
> 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.

I think this vagueness is somewhat purposeful.  It is not directly allowed
or prohibited.  Whether or not a self-signed certificate is found within the
path, the path is still complete.  Any benefit or detriment that comes from
having the self-signed certificate within the path will not always be
encountered for two reasons, 
	1) Other implementations may not allow the path to have a
self-signed certificate within it
	2) You may find the path without the self-signed certificate first

> 
> 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 think it is a bad idea for Bridge CAs to post self-signed certificates in
the directory.  They are not a trust anchor for anyone, so they should not
publish a self-signed certificate as a key container.  However this point
and demonstration remain the same if you consider just three CAs that have
cross-certified without a bridge.
 
> 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 ?

Again, my opinion is that since both are complete paths, both are equally
valid and may be used by different implementations.  However, many
implementations have made a simplifying assumption to prevent certificate
path loops which would prevent #2 from ever being validated.  So any benefit
that might be gained by allowing #2 cannot be counted on.

There seems to be little benefit gained by including two or more
certificates with the same subject distinguished name and subject public key
within the same path.  I have looked through your examples below and must
admit I am not understanding them fully.  Let's look at this example

TR -> A -> B -> (B self signed) -> C -> EE

Let's say that A->B has a notAfter date of 12/31/2002, (B self signed) has a
notAfter date of 12/31/2001, and B->C has a notAfter date of 12/31/2002.  If
this path was developed and validated, the path would be invalid if the
current date was after  12/31/2001.

> * 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.
> 

In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle in which you encounter
two people at a crossroads, a truthteller and a liar.  You do not know which
is which, and must ask one of them a question in order to know if you should
turn left or right to get to where you want to go.  

--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

> 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...?
>