Subject: RFC 3280 and trust anchor selection

From: Ville Heikkala <[email-masked]>
Date: Fri, 20 Oct 2006 14:00:19 +0300 (EET DST)

Dear all,

draft-ietf-pkix-rfc3280bis-05.txt states in section 6 that, quote,

   The selection of a trust anchor is a matter of policy: it could be
   the top 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
   validation procedure is the same regardless of the choice of trust
   anchor.  In addition, different applications may rely on different
   trust anchors, or may accept paths that begin with any of a set of
   trust anchors.

and later on

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated (i.e., the
      target certificate); and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.

   A certificate MUST NOT appear more than once in a prospective
   certification path.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.

According to the first quoted paragraph above, we have some freedom in
choosing the trust anchor. The last paragraph above seems to imply that
only self-signed trust anchors are excluded from the prospective
certification path. However, (b) above seems to imply that any trust
anchor (self-signed or not) would not be included in the path. The same
impression is given by section "6.1.1 Inputs" where we have

      (a)  a prospective certification path of length n.

and, as a separate input,

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes: ...

My question is: are all kinds of trust anchors to be excluded from the
path or only self-signed ones? This came up when considering the following
kind of hierarchy:

RootCA (self-signed)

SubCA issued by RootCA with certificatePolicies containing some policy A
and having PolicyConstraints/requireExplicitPolicy equal to 0 (I'm not
sure if this is relevant though)

EE with another policy B different from A

Assume that neither A nor B is anyPolicy.

According to the above quote (first paragraph) we may choose either
RootCA or SubCA as the trust anchor. And I've seen real-life setups
similar to this one where SubCA was chosen as the trust anchor.

Now, having RootCA as the trust anchor means that EE will not validate
because its policy doesn't match that of SubCA.

However, having SubCA as the trust anchor, EE will validate if SubCA is
not included in the path and will not validate if SubCA is included.

Which way is it?

Thanks,

Ville Heikkala
SSH Communications Security Corp.

---

From: "Kemp David P." <[email-masked]>
Date: Fri, 20 Oct 2006 12:45:41 -0400

If the trust anchor is derived from SubCA, EE will validate.

This is not a contradiction or paradox when you consider section
6.1.1(d):

--------------------
      information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
         with the public key.
--------------------

This means that a trust anchor, which is installed out-of-band,
does not need to be provided in the form of a certificate at all,
whether self-signed or not.  If the trust anchor information does
happen to be contained in a certificate, no information from
that certificate except 1-4 above is included in the trust anchor.

When SubCA's cert is included in the path, the policy conflict
occurs.  When SubCA's name and public key is used as a trust
anchor, there is no policy conflict.

When SubCA's name and public key is used as the trust anchor,
SubCA's certificate cannot possibly be part of the path because
the certificate is issued by RootCA, not self-issued.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ville Heikkala
Sent: Friday, October 20, 2006 7:00 AM
To: [email-masked]
Subject: RFC 3280 and trust anchor selection

[...]

Which way is it?

Thanks,

Ville Heikkala