RE: Path validation and self-signed certificates

[Peter Williams <peterw@xxxxxxxxxxxx>]

I disagree with your recommendation. I am thinking
as an long-term implementor who has followed
and interpreted the particular X.509 guidance through
5 generations of PKI software now, when I say the 
following:

Anyone can send any set of certificates in a proposed path; it
is for the receipient to sort, and select, which certs represent
a trust path that meets their local security policy 
requirements. This includes choosing certs based on their
convergence with locally-recognised trust anchors.

For example, one can send two parallel paths to
a given recipient in the certs list of a PKCS7 
msg, each of whose trust-anchors may be indicated by a 
self-signed cert.

The one path (of the two sent) to be actually validated depends upon the 
receivers application software, not the PKIX path processing
algorithm.  Upon discovery, elements of the selected path should be 
then passed to the X.509 path processing
algorithm implementation. In a good implementation
of the application, the passed path will include only those 
elements of the trust path that meet the path processing rules; 
this should does not include the self-signed cert. If found,
the self signed cert should be ignored by the security module
evaluated to ensure conformance to PKIX/509.

Of course, how the path processing algorithm learns which
trust anchors are legitimate is something that is 
not-standardized, and should not be indicated to the algorithm 
by information derived from a cert path. If the application
before passing the cert path to X.509 path processing
has setup a path-processing security context with the two trust
anchors recently delivered via self-signed certs,
then this is acceptable application practice. If we were
building PEM, perhaps the IPRA public key would be
pre-installed in every security context...

Lets remember, its not IETF business to standardize the 
non-Internet applications that use PKI; of which there are now
many. They discover paths and control trust anchors however
they wish. It is PKIX business to ensure that two path processing
algorithm given the same inputs would
produce the same result concerning a valid path. After 
10 years of trying, we are about as far from this
goal as ever, unfortunately, in Internet praxis. 

Peter.

-----Original Message-----
From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
Sent: Saturday, August 25, 2001 2:33 PM
To: ietf-pkix@xxxxxxx
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