Subject: Re: WG Last Call: Roadmap

From: "Tom Gindin" <[email-masked]>
Date: Fri, 5 Apr 2002 01:46:45 -0500

Responses below, set off by [Tom] - no initials, for obvious reasons.
I don't actually understand why a self-signed certificate is preferable to
a cross certificate with constraints as a trust anchor in cases where both
exist and refer to the same CA.

            Tom Gindin

"todd glassey" <[email-masked]> on 04/04/2002 12:33:29 PM

To:    "Denis Pinkas" <[email-masked]>, Tom Gindin/Watson/IBM@IBMUS
cc:    <[email-masked]>
Subject:    Re: WG Last Call: Roadmap

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 03, 2002 8:15 AM
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.

Perhaps but I would like to point out that the terminology invites
confusion. It should refer to whatever is the trust anchor here.

The key problem with this use is that the indemnetor or guarantor of the
trust may not be the systems operator and so then the "CA's uses only" will
stand for first-person models.

[Tom] Actually, Todd, the main purpose of distinguishing "root" from "Top"
here is to define "root" as equivalent to trust anchor.  Perhaps using
near-synonyms for these terms is a bad idea, but it's surely better than
using the same word for both.

>
> 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.
>
> >       The second is less minor.  Is it truly intended that a signing EE
> > be permitted to specify the set of trusted CA's for an RP to use in
> > verifying a signature?  At a minimum, an RP in this model is
responsible
> > for validating the the set of rules is identical to one it has already
> > decided to trust, but there is no reference in the model description to
> > any active role for the RP.
>
> A verifier (not a signing EE as you mentioned) does not know what an
anchor
> is, but may know what a policy is. So by selecting the policy that
applies
> to the application, indirectly trust anchors (and much more) are
selected.
> Remember that the same verifier may verify digital signatures in various
> contexts, e.g. for a Bank transaction or for a green reservation in a
Golf
> Club. The trust conditions are not necessarilly identical. Note also that
a
> verifier does not need to be a signer and may not have any certificate of
> its own.
>
> The case of a single (root) CA trusted for any kind of application is a
very
> specific case and cannot be considered as the general case.
>
> >       In your comment 5 (on page 15), replace "date of issue" by "date
and
> > time of issue".
>
> This is fine.
>
> >       At a slightly more substantive level, shouldn't the clarification
of
> > the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> > directly trusted by the EE."?  This wording permits multiple trusted
roots.
>
> I do not think that PKIX-1 allows for this. See the quote above.
>
> >       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> > certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> > certificate", and your definition excludes it.  Then the sentence "Some
> > people in the WG believe that a cross certificate is a special kind of
CA
> > certificate." is reversed to "... believe that a hierarchical CA
> > certificate is a special kind of cross certificate".

Here again we might refer to the Trust Anchor for this transaction rather
than the CA itself. There is too much complexity in a free form trust
system
that has no global standards for its use to date.

A better solution would be to use a more general and as such higher level
language about the Anchoring process or otherwise use of the certificates.

[Tom] This particular comment distinguishes types of CA certificates.  We
do go into trust anchors at other points, but being specific about CA's is
useful here.

>
> You say that the definition excludes the fact that a Top CA's self-signed
> certificate is also a CA-certificate. This is correct, ... but was not
> intended.
>
> So what about this full correction ?
>
> [2459bis] defines a cross-certificate as "a certificate issued by one CA
to
> another CA". [2459bis] does not provide a formal definition of a CA
> certificate but implictly means a certificate where the subject of the
> certificate is a CA.

> This means that self-signed certificates are CA
> certificates but are not cross-certificates.

cant or better yet, shouldn't the ultimate source of any trust chain have a
self-signed cert as its core anchor? Just makes sense I think.

[Tom] Why is a self-signed certificate a better anchor than a
cross-certificate with constraints in it?  This question is most applicable
to cases where the trust anchor is NOT a top CA.

> Some people in the WG believe
> that a cross certificate is a special kind of CA certificate issued by a
CA
> under one Top CA for another CA under a different Top CA.

these are use rules and have little to do with the protocol itself.

> CAs in the same
> hierarchy usually have part of their names imposed by the Top CA or by
the
> CAs under that Top CAs. When a cross certificate is issued, there is no
> relationship between the names of the CAs.
>
> >       In comment 11, the i.e. should remain "what are the root CA's"
rather
> > than "what are the Top CA's", for the same reason as in comment 12.
>

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 11 Apr 2002 07:46:17 -0400

Al:

      Your argument against updating the terminology is pretty convincing.
We should probably provide a note that the term "trust anchor" is normally
used with roughly the same meaning as "root CA" in this document.  The term
is fairly commonly used, and unambiguous.

            Tom Gindin

Al Arsenault <[email-masked]> on 04/10/2002 01:28:43 PM

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

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

----- Original Message -----
From: "Tom Gindin" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 10, 2002 10:41 AM
Subject: Re: WG Last Call: Roadmap

>
>
>       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]
> >       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]
> > 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]
> > > [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.
> >
> > (...)
> >
> >    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)
>
>
>
>