Using certificates as trust anchors

[Yassir Elley <yassir.elley@xxxxxxx>]

In looking over draft-ietf-pkix-new-part1-01.txt, a question
arises as to how to process trust anchors provided in the
form of a self-signed certificate. Since many applications use such certificates
as trust anchors, I think it is important for PKIX to explicitly spell out how
to process these certificates.

Section 6.1.1 describes the five pieces of trust anchor information and
mentions that the trust anchor information may be provided in the form
of a self-signed certificate.

"(d) trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor infor-
      mation includes:
         (1) the trusted issuer name,
         (2) optionally, the trusted issuer unique identifier,
         (3) the trusted public key algorithm,
         (4) the trusted public key, and
         (5) optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path process-
      ing procedure in the form of a self-signed certificate. The
      trusted anchor information is trusted because it was delivered to
      the path processing procedure by some trustworthy "out-of-band"
      procedure.  If the trusted public key algorithm requires parame-
      ters, then the parameters are provided along with the trusted pub-
      lic key."

However, in other parts of Section 6, we find that the algorithm
also requires the validity period of the public key, as well
as other constraints (presumably this refers to initial
name constraints, policy constraints, basic constraints[pathLenConstraint]?).

For example:
"In section 6.1, the text describes basic path validation. This text
   assumes that all valid paths begin with certificates issued by a sin-
   gle "most-trusted CA". The algorithm requires the public key of the
   CA, the CA's name, the validity period of the public key, and any
   constraints upon the set of paths which may be validated using this
   key."

Section 6.2 also refers to making use of the certificate's extensions
to limit the path.
 "Limitations in the trust paths for any particular key may
   be incorporated into the self-signed certificate's extensions. In
   this way, the self-signed certificates permit the path validation
   module to automatically incorporate local security policy and
   requirements."

If the trust anchor information is provided in the form of a self-signed
certificate, we can certainly extract the five pieces of trust anchor
information mentioned in Section 6.1.1.

Should we also be extracting other information from the certificate,
such as policy constraints, policy mappings, name constraints, and
basic constraints, and using these to initialize the relevant state
variables? What about the validity period of the public key?
Do we need to verify that the self-signed certificates's validity period
includes time T?

Do we need to validate the self-signed certificate itself?
(i.e. do we have to verify the self-signed certificate's signature,
revocation status, name chaining, uid chaining, that any
certificate policies and policy mappings are processed,
that it is a CA cert, that it has a keyCertSign key usage asserted,
that all critical extensions are processed?)

If the trust anchor information is trusted because it
was delivered "out-of-band", can we use non-self-signed
certificates to provide the trust anchor information?
Perhaps I have a certificate that is not self-signed that I
trust for some "out-of-band" reason. I would think
that I should be able to use this certificate as a trust anchor
since I have designated it as trusted. If this is allowed,
it should be noted that we will not be able to
validate the signature, revocation status, name chaining,
and uid chaining checks because these checks rely
on a "previous" certificate's values which we don't have.

One approach would be to not validate any part of
the trust anchor certificate and simply accept it
(whether or not it is self-signed)
because the user has designated it as "trusted", but
to extract any relevant information. In other words,
we wouldn't perform any of the steps in
6.1.3 (Basic Certificate Processing) but we would
perform all the steps in 6.1.4 (Preparation for
Certificate i+1).

All of these questions need to be answered explicitly
so that we can all process trust anchor certificates in
a standard way.

-Yassir.