Subject: RE: Path validation and self-signed certificates

From: "David A. Cooper" <[email-masked]>
Date: Sat, 25 Aug 2001 17:33:29 -0400

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

---

From: Steve Hanna <[email-masked]>
Date: Mon, 27 Aug 2001 12:00:28 -0400

I agree with David on this.

One more reason that self-signed certificates should be forbidden in
path validation is that, if they are allowed, there are situations
where a path may be valid if a self-signed certificate is added to
it and invalid otherwise (if the self-signed certificate contains
policy mappings, for instance). This situation should never arise
in a well-managed PKI, but it means that in order for a path
discovery library to be *absolutely* certain that no valid path
can be constructed from a given set of certificates, self-signed
certificates must be considered. In fact, there are cases where a
self-signed certificate may need to appear multiple times in a row!
This makes path discovery even harder than it was before. If we
require that self-signed certificates be forbidden or ignored in
PKIX path validation, none of this will be a concern.

I suggest that son-of-2459 forbid the use of self-signed certificates
in paths. We should require that any path containing a self-signed
certificate be regarded as invalid.

It's tempting to simply ignore self-signed certificates, as X.509
now does. This would provide maximum compatibility with X.509 and
handle the common case where a trust anchor is accidentally included
at the start of a certification path. But I think this can lead to
security holes. If a self-signed certificate is the last certificate
in the chain and validation of the chain succeeds, a naive
application may extract the subject alternative name or other fields
from the self-signed certificate and assume that they have been
validated (when in fact the entire certificate was ignored). We could
forbid the use of self-signed certificates as the last certificate in
the chain and specify that they are ignored otherwise, but this just
complicates the algorithm. And do we really want to allow a valid
path to contain a certificate whose revocation status and signature
has not been checked?

Simply discouraging the inclusion of self-signed certificates in
certification paths but not forbidding their inclusion leaves open the
question of how validation routines should process them. This
increases the chances of the problems described below. So I recommend
that son-of-2459 specify that any path that contains a self-signed
certificate is invalid.

-Steve

"David A. Cooper" wrote:
> 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!
!
!

---

From: Hiroyuki Sakakibara <[email-masked]>
Date: Tue, 28 Aug 2001 11:48:07 +0900

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 : [email-masked]

----- Original Message -----
From: "David A. Cooper" <[email-masked]>
To: <[email-masked]>
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:
> 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!
> 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.
> >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.