RE: Path validation and self-signed certificates

["David A. Cooper" <david.cooper@xxxxxxxx>]

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