Subject: Re: WG Last Call: Roadmap

From: "Tom Gindin" <[email-masked]>
Date: Tue, 9 Apr 2002 10:46:34 -0400

Denis:

      Should we really standardize on the term "root CA" rather than "trust
anchor" or "anchor CA"?  "Trust anchor" has never been used to mean
anything other than an entity directly trusted by the RP, AFAIK.  I have
other comments below.

            Tom Gindin

Denis Pinkas <[email-masked]> on 04/08/2002 12:32:41 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked]
Subject:    Re: WG Last Call: Roadmap

Tom,

I have not forgotten this message, but I gave priority to the DPV thread.

>       Responses below.

> The issue of who specifies the verifier's policy is
> rather serious.  If the policy to be used is expected to be the same as
RFC
> 3126's SignaturePolicy, we need to specify a step in which the verifier
has
> the right to reject such a policy or to consider it inapplicable to the
> verifier's own current context.

This is true. However, the text does not go at that level of detail:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules.
When choosing to use certificates in the context of that application,
the EE selects the set of rules for that context. In a set of rules,
one or more Top CAs may be trusted, each one may be associated with
different constraints, like the certificate policies that are trusted
or the naming constraints that apply. These constrains may be specified
either in self-signed certificates or in addition to self-signed
certificates when they do not incorporate these constraints. This set
of rules is called a validation policy (when validating a certificate)
or a signature policy (when validating a digital signature)."

I do not think it is necesary to state it. If you think so, please provide
a text and a placement for that text.

[TG] My biggest problem is the use of the term "signature policy", which
you have elsewhere defined as something defined and signed by the signer of
the document.  In the paragraph above, I would replace the term "Top CAs"
by "root CA's", and I would also call the sets of rules in the last
sentence a "certificate validation policy" and a "signature validation
policy".  I would then add the following statement: "Neither of these
policies is considered to be the same as either a CertificatePolicy as
defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."

>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [email-masked]
> Subject:    Re: WG Last Call: Roadmap
>
> Tom,
>
> >       I have a few issues with this, and some corrections as well.
>
> >       In comment 12, I have two issues.  The first one, which is minor,
> is
> > that  "one or more Top CA's may be trusted" should refer to root CA's
> > instead - the two terms mean the same thing more often than not, but
when
> > they differ the trust point is the root rather than the top.
>
> PKIX-1 states:
>
>    " - Top CA - A CA that is at the top of a PKI hierarchy.
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE."
>
> The problem lies with the last sentence, i.e. "*the* CA directly trusted
by
> the EE.". The singular is being used which means that there is a single
> one, multiple roots are not permitted, while multiple Top-CAs are
> permitted.
>
> [TG] Where in PKIX-1 is this?  I can't find the phrase "directly trusted"
> in either RFC 2459 or in draft 12 of new-pkix-1.

Sorry for the confusion: it is in the roadmap document, not PKIX-1.

The current text in the roadmap is:

    " - Root CA - A CA that is directly trusted by an EE; that is,
       securely acquiring the value of a Root CA public key requires
       some out-of-band step(s). This term is not meant to imply that a
       Root CA is necessarily at the top of any hierarchy, simply that
       the CA in question is trusted directly.

(...)

   Note: This is often also called a "Root CA," since in data structures
   terms and in graph theory, the node at the top of a tree is the
   "root." However, to minimize confusion in this document, we elect to
   call this node a "Top CA," and reserve "Root CA" for the CA directly
   trusted by the EE. Readers new to PKIX should be aware that these
   terms are not used consistently throughout the PKIX documents, as the
   Internet PKI profile [2459bis] uses "Root CA" to refer to what this
   and other documents call a "Top CA," and "most-trusted CA" to refer
   to what this and other documents call a "Root CA."

There is no problem with PKIX-1 but a problem with the roadmap document.
PKIX-1 does not use the term "root CA", and thus it is wrong to say in
the roadmap that "these terms are not used consistently throughout the
PKIX documents".

I would thus propose to change the note in the following way:

   Note: Since in data structures terms and in graph theory, the node
   at the top of a tree is the "root", the term "root CA" is sometimes
   used. This term is not meant to imply that a Root CA is necessarily
   at the top of any hierarchy, simply that the CA in question is trusted
   directly.

[TG] As I stated at the beginning, I don't know why we should standardize
on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
approve of that coinage.

Then, on page 14, change:

   Additionally, once the Root CA ...

with

   Additionally, once a Root CA ...

on pages 29 and 30, change:

   (e.g., the DVCS's CA, or the Root CA in a
   hierarchy)

with

   (e.g., the DVCS's CA, or a Root CA)

Regards,

Denis

(snip)

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Apr 2002 18:00:26 +0200

Tom,

> anchor" or "anchor CA"?  

I do not care, but I care for this document to be sent to the IESG soon. So
the sooner we may find a compromise, the better. Maybe the quickest way
is to try to suppress the sentences that create problems. We should
focuss on text replacement proposals.

> "Trust anchor" has never been used to mean anything other than an entity directly trusted by the RP, AFAIK.  

Not exactly. Read this sentence again.  However, I would like to resist to
start a new discusion now on trust anchors.

> I have other comments below.
> 
>             Tom Gindin
> 
> the document.  

There is a misunderstanding. A signer may provide the *reference* of the
signature policy that he agrees to use when signing. In order to prevent
someone else to change that reference, it is protected by the signer's
signature. So in that case the verifier has first to see whether the
signature policy used by the signer is appropriate for his application
context. If it is the case, then it uses it, otherwise this is the end of
the story.

> In the paragraph above, I would replace the term "Top CAs"
> by "root CA's", 

No problem.

> and I would also call the sets of rules in the last

I would simply propose to delete the following sentence:

"This set of rules is called a validation policy (when validating a
certificate) or a signature policy (when validating a digital signature)"
not because it is wrong, but because I would like this document to proceed.

This would lead to the following text:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules.
When choosing to use certificates in the context of that application,
the EE selects the set of rules for that context. In a set of rules,
one or more root CAs may be trusted, each one may be associated with
different constraints, like the certificate policies that are trusted
or the naming constraints that apply. These constrains may be specified
either in self-signed certificates or in addition to self-signed
certificates when they do not incorporate these constraints." 

Can you live with it ?

> terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I

We do use "root CA", so I see no harm to use that vocabulary. This is no
attempt to standardize this term here. Originally my single concern what
that the text was talking about *one* root CA whereas there can be multiple.
This was my ONLY concern. This is now fixed. We should close this issue
ASAP.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Tue, 9 Apr 2002 09:03:18 -0700

For what it is worth- the term Trust Anchor is something that I coined at
Coastek some number of years ago  (1997) and is specific to an evaulated set
of trust processes. What I mean by that is that a trust anchor is the
uppermost anchoring trust element to which all others are referenced to or
through but that this is also specific to a particular transaction or set of
transactions.

The intent was/is to define on a per transaction basis a uniform point of
anchoring these referencable datasets. As to the mechanics of the process,
the term ROOT CA is the mechanical analog of the trust anchor only for the
mechanics of the transaction and not the content of the transaction per se.

The term "trust anchor" was/is to remove any ambiguity on a transaction
specific basis, and the term ROOT CA is more likely to be accepted as the
mechanical top of the pyramid (i.e. as part of the plumbing and not its use
per se.)

Todd