RE: Using certificates as trust anchors

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Yassir asked:

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

draft-ietf-pkix-new-part1-01.txt, section 6, paragraph 4 states:

   The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path valida-
   tion procedure is the same regardless of the choice of "most-trusted
   CA."

My interpretation of the above paragraph is yes, the trust anchor need not
be a self-signed root certificate, which leads me to ...

I have a difficult time comprehending section 6 of RFC 2459 and
draft-ietf-pkix-new-part1-01.txt. I believe the reason is that many terms
are used without first being clearly defined. For example, the term root CA,
in the above paragraph, appears once without being defined. The term root
certificate does not appear in draft-ietf-pkix-new-part1-01.txt. As an
aside, I would love to know how many times the terms root CA or root
certificate appear in PKIX-related implementations, either in comments or
variable names.

Is there interest in formally defining the terms used in section 6? If yes,
I would be more than willing to take a stab at defining the terms I deem
relevant, including:

certificate [Is currently defined in section 3.1.]
certificate hierarchy
root certificate
superior (or parent) certificate
subordinate (or child) certificate
self-signed certificate
trusted certificate
certificate (or certification) path [Is currently defined in section 3.2.]

Perhaps this would make it easier to for developers (such as myself) to
convert the narrative into code.

Frank

> -----Original Message-----
> From: Yassir Elley [mailto:yassir.elley@sun.com]
> Sent: Tuesday, June 20, 2000 2:45 PM
> To: ietf-pkix@imc.org
> Subject: Using certificates as trust anchors
> 
> 
> 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.
> 
> 
> 
>