Peter -
I agree with your
comments on self-signed certificates in chains with only one exception, specifically
in regards to revocation. There are several cases where the revocation of a
self-signed CA would make sense, what about cessationOfOperation,
superseded and affiliationChanged? These reasons do not
imply any sort of compromise of key material. We make many "known assumptions"
in PKI and the catch 22 of key material management and trust is one of them, without
these "known assumptions" many of the things in son-off fall apart J.
Ryan
-----Original Message-----
From: Peter Hesse [mailto:pmhesse@xxxxxxxxxxxx]
Sent: Wednesday, August 22, 2001
6:46 AM
To: 'Hiroyuki Sakakibara';
Housley, Russ; Peter Hesse
Cc: ietf-pkix@xxxxxxx
Subject: Path validation and
self-signed certificates (was RE: Recommended changes to
draft-ietf-pkix-new-part1-08)
Hiroyuki,
I will attempt to discuss a few of these issues
inline.
> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:sakaki@xxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, August 22,
2001 1:51 AM
> To: Housley, Russ; 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
>
>
> 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...?
>