Subject: Re: WG Last Call: Roadmap

From: "Tom Gindin" <[email-masked]>
Date: Wed, 10 Apr 2002 10:41:39 -0400

It is obviously important that this document get finalized fairly
soon.  The only question we have outstanding is whether "root CA" as
defined would be better replaced by "anchor CA" or "trust anchor".  This
should not block the document for more than a day or two, but I think it
worthwhile to find out what you think the difference is.  The term "root
CA" as "root of trust" has caused some confusion in these discussions, and
if there's a better term which is in fairly common use (as "anchor" is) we
should use it.  If there's a real difference, we should keep "root CA".  In
case it's not obvious, the term "anchor CA" means "a trust anchor which is
a CA" - which assumes that trust anchors could be defined in such a way
that they might be EE's or even AA's.

            Tom Gindin

Denis Pinkas <[email-masked]> on 04/09/2002 12:00:26 PM

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

Tom,

>       Denis:
>
>       Should we really standardize on the term "root CA" rather than
"trust
> 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
>
> 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.

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.

[TG] He mainly needs to check whether it's an approved signature policy by
his personal or organizational criteria.

> 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
> 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."

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 ?

[TG] Sure.

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

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

> 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: Wed, 10 Apr 2002 17:08:58 +0200

Tom,

> It is obviously important that this document get finalized fairly soon.  

Indeed.

> The only question we have outstanding is whether "root CA" as
> CA" as "root of trust" has caused some confusion in these discussions, 

Maybe.

> and
> if there's a better term which is in fairly common use (as "anchor" is) 

I wonder. "Anchor" or "trust anchor" is a term that few people understand
(and there is no unanimity on its meaning). Root CA has been used (or
mis-used ?) for years. We cannot ignore thee fact that "root CA" is being
used.

> we should use it.  If there's a real difference, we should keep "root CA".

There is a real difference, since you mention that a trust anchor could be
defined in such a way that they might be EE's or even AA.

By opposition a root CA is always a CA, not necessarilly a Top CA. This is
what the current text says. So these terms are not equivalent

So if I take your previous statement, i.e. "If there's a real difference, we
should keep "root CA", I let you draw the conclusion.

Denis

> In case it's not obvious, the term "anchor CA" means "a trust anchor which 
> is a CA" - which assumes that trust anchors could be defined in such a way

---

From: Al Arsenault <[email-masked]>
Date: Wed, 10 Apr 2002 13:28:43 -0400

Tom,

    Going back to how that discussion got started lo those many years ago,
the problem was that different PKIX documents used the term "root CA" to
mean different things.  Most of them used it to mean "trust anchor" or some
similar thing; i.e., "this is the CA that you base all of your trust on as
an RP" (and yes, in a large complex PKI system there might be more than one
of these); a few used it as a synonym for "top CA"; i.e., the thing at the
top of a hierarchy.

    After much discussion on this list, the terms as they now appear in the
Roadmap document were agreed to (okay, it was pretty darned rough consensus,
but it was as good as we were gonna get at that time).  This made the
Roadmap pretty consistent with other PKIX documents, and I think "best
efforts" were made to bring the usage in the other documents into line over
the years.

    So I'd be really hestitant to change the terminology in the Roadmap
now - it'd just bring up the same old issue again, and cause the roadmap to
be inconsistent with (almost) all of the other PKIX documents - which is not
something I'd want.

    Thanks,

            Al Arsenault