[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path validation and self-signed certificates
David
Thank you for four comments.
In (2) and (4), as you mentioned, following the latest X.509 standard,
if a validation system tries to check extensions in self-signed
certificates,
certificatePolicies, nameConstraints etc,
the result of validation will not be identical to the result of validation
ignoring self-signed certificates and will be an interoperability problem.
I think that IF a validation system checks self-signed certs,
the software shall check validity and revocation only,
because these are additional checks to enhance security of validation.
But the current X.509 does not allow these processing unfortunatelly.
David Cooper ----->
Hiroyuki Sakakibara presented an example in which processing self-signed
certificates helped to prevent a security breach. In his example, A issues
a cross-certificate to B and B's private key is compromised. Hiroyuki
pointed out that by processing B's self-signed certificate (to see if it
has expired or has been revoked) one may have a chance to detect the
compromise even if A does not cooperate by revoking the certificate that
it issued to B. However, as he pointed out, this is not foolproof. The
entity that
compromised B's key could issue a new self-signed certificate with a later
notAfter date along with CRLs that make it appear as if B's certificates
are still good. If on the other hand, B were able to get its own CRLs to
relying parties, it could just revoke all of its certificates instead of
just its
self-signed certificate, thus ensuring that any relying party that receives
its CRLs will know that its certificates can not be trusted, whether they
process B's self-signed certificates or not.
<-----David Cooper
OK, I see.
as your example ( also in (3) ), in the case of revocation of B,
B can announce its revocation by issuing a CRL that containts all certs
that B issued(including its self-signed),
even though A does not issue a CRL which revokes a cert from A to B.
In the case of revocation of Bridge CA, a CRL issued by Bridge CA
would be large depending on the number of CAs it cross certifies with.
Killing Bridgne CA itself only in the CRL, size of it will be quite small.
David Cooper ----->
In general though, if a certification path of the form ... --> A --> B -->
... is being processed, I don't think there is much that B can do to
protect relying parties from A's improper behavior. If A issues certificates
to B
with notAfter dates that are later than they should be or if A refuses to
revoke B's certificate when requested to do so, there is little that B can
do to protect A's relying parties (or the relying parties of any CA that
preceded A in the path) from A, particularly in the case when B's private
key has been compromised.
<----- David Cooper
I agree with you.
I still suppose that checking self-signed certs validity (notBefore/After)
or revocation would be some help to detect improper behavior of A
in some cases.
And considering Peter's comments, some implementation would validate
self-signed certs though it would be rare.
Peter Hesse ----->
- Not all certificate validation systems allow any self-signed
certificates to appear as intermediate certificates in paths.
This is primarily for two reasons: 1) Preventing same subject name and
public key from appearing twice in a path prevents loops, and
2) some argue that the same public key appearing twice in the path dilutes
the trust chain.
<-----Peter Hesse
While I think that validating self-signed certs in a path would be
meaningful,
it would not possible for a RP to find self-signed certs always.
Because, when the RP does not find a self-signed cert for a CA,
the RP could not automatically judge that "a self-signed cert for this CA is
not present in LDAP by accident"
or
"originally it does not exist( was not issued)",
on the other hand, the RP can construct a path without self-signed certs.
Is there any idea that a RP detects CA's improper behavior ... ?
------------------------------------------------------------------------
[my personal opinion]
I would like to summurize my personal opinion considering replies from
Peter and David.
* the latest X.509 inhibits validation of self-signed certs in a path.
On the other hand, some implementation already would have adopted
cheking self-signed certs, and in some cases it would be meaningful,
therefore it is not good that self-signed certs are entirely ignored.
"may be ignored" is better, I think.
* PKIX shall follow X.509. For interoperability,
as most of implements would have applyied,
if self-signed certs appear in the middle of a path,
they shall be ignored, WHEN VALIDATION, not construction.
Namely, this processing is the subset of the above bullet
( self-signed certs "may" be ignored in the above bullet)
------------------------------------------------------------------------
I thank for Peter Hesse and David A. Cooper 's many comments.
While I still suppose that it is meaningful to check self-signed
certificates in some cases,
I suppose that cheking self-signed certificates does not protect a CA's
improper behaivior always and perfectly and
a path will be longer and complicated than one without self-signed certs.
Anyway, I think it is better that son of 2459 describes some recommendations
about including / not including self-signed certs in a path.
In this case, the latest X.509 ignores self-signed certs when
validation( not construction), hence, son of 2459 reccomends that
coresspondingly.
[Question]
I have a related question about path construction and validation.
Based on the current X.509, a path may containts self-signed certs,
however, they shall be ignored when validation.
For example,
B issues its EndEntity a certificate whose AKI explicitly indicates
B's self-signed with authorityCertIssuer/SerialNumber.
Relying Parties in B's PKI system use B's self-signed as the trust anchor's
cert.
Later, A and B agree with cross-certification between them,
then, A issues a cross certificate to B.
hence, a path in the cross certification may be constructed as
(1) A->B, B(self-signed), B->EE
or
(2) A->B, B->EE
(1) refferencing AKI of B->EE which explicitly indicates B(self-sign)
with authorityCertIssuer/SerialNumber
(2) ignoring AKI of B->EE or refferencing keyId in AKI only if exists.
According to the latest X.509, even thogh a path is constructed as (1),
B(self-signed) shall be ignored when validation.
Is my interpretation correct ?
or self-signed certs shall be ignored when path construction ?
( if they are ignored when path construction, it will be more efficient.)
Hiroyuki Sakakibara
---------------------------------------
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 : sakaki@xxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "David A. Cooper" <david.cooper@xxxxxxxx>
To: <ietf-pkix@xxxxxxx>
Sent: Sunday, August 26, 2001 6:33 AM
Subject: RE: Path validation and self-signed certificates
>
> All,
>
> I believe that PKIX should either discourage or forbid the inclusion of
self-signed certificates in certification paths for the following reasons:
>
> 1) Section 8.1.5 of the 4th edition of X.509 states that
>
> There are three circumstances under which a certification
authority may
> issue a certificate to itself:
>
> a) as a convenient way of encoding its public key for
communication to,
> and storage by, its certificate users;
>
> b) ...
>
> For purposes of path validation, self-issued certificates of type
a) are verified
> with the public key contained in them, and if they are
encountered in the path,
> they shall be ignored.
>
> So, X.509 states that self-signed certificate are only to be used as a
convenient way of encoding a public key, and that self-signed certificates,
if they are encountered in a certification path are to be ignored. Thus, if
PKIX were to allow the processing of self-signed certificates, it would not
be compliant with X.509.
>
> 2) As Peter Hesse pointed out, many CAs issue self-signed certificates
with a minimum necessary information (e.g., a version 1 certificate with
just a name, public key, and validity dates). Any such certificates
included in a certification path would result in an empty valid_policy_tree.
Old-with-new and new-with-old self-issued certificates are designed to be
used as part of certification paths and so should contain all of the
necessary extensions (e.g., basicConstraints, certificatePolicies), but
self-signed certificates may be been issued simply as a means of
distributing the public key to relying parties that will use that key as a
trust anchor. If these certificates are included in, and are processed as
parts of, certification paths, the results may be rejecting end certificates
that should be have been accepted.
>
> 3) If a CA suspects that its key has been compromised (or it otherwise
determines that none of the certificates it has issued should be considered
valid), it should request that every certificate issued to it be revoked (as
is stated in the Security Considerations section). If possible, it should
also revoke all of the certificates it has issued (not just its self-signed
certificate). If a CA can revoke its own self-signed certificate then it can
revoke all of the certificates it has issued. Doing so will ensure that all
relying parties know about the revocation, not just those relying parties
that check to see whether the signed-signed certificate has been revoked.
>
> 4) If an organization uses client software that processes self-signed
certificates, there is risk that that organization will issue certificates
from its own CA assuming that relying parties process self-signed
certificates. This organization's CA may then issue self-signed certificates
with constraints (e.g., name constraints, path length constraints, etc.)
that they expect relying parties to see, but the CA, assuming that relying
parties will process its self-signed certificates, may not include the
constraints in any of its other certificates.
>
> So, if there is no set rule, there is the risk that relying parties that
do process self-signed certificates will lose some interoperability and
those that do not will overlook intended path processing constraints.
>
> Hiroyuki Sakakibara presented an example in which processing self-signed
certificates helped to prevent a security breach. In his example, A issues
a cross-certificate to B and B's private key is compromised. Hiroyuki
pointed out that by processing B's self-signed certificate (to see if it has
expired or has been revoked) one may have a chance to detect the compromise
even if A does not cooperate by revoking the certificate that it issued to
B. However, as he pointed out, this is not foolproof. The entity that
compromised B's key could issue a new self-signed certificate with a later
notAfter date along with CRLs that make it appear as if B's certificates are
still good. If on the other hand, B were able to get its own CRLs to relying
parties, it could just revoke all of its certificates instead of just its
self-signed certificate, thus ensuring that any relying party that receives
its CRLs will know that its certificates can not be trusted, whether they
process B's self-s!
> igned certificates or not.
>
> In general though, if a certification path of the form ... --> A --> B -->
... is being processed, I don't think there is much that B can do to protect
relying parties from A's improper behavior. If A issues certificates to B
with notAfter dates that are later than they should be or if A refuses to
revoke B's certificate when requested to do so, there is little that B can
do to protect A's relying parties (or the relying parties of any CA that
preceded A in the path) from A, particularly in the case when B's private
key has been compromised. I don't think that it is worth diverging from
X.509 and introducing interoperability problems into PKIX in an attempt to
try.
>
> Dave
>
> At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
> >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.
> >
> >Ryan
>
>
>