Subject: Re: WG Last Call: Roadmap

From: "Tom Gindin" <[email-masked]>
Date: Thu, 4 Apr 2002 07:50:50 -0500

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.

            Tom Gindin

Denis Pinkas <[email-masked]> on 04/03/2002 11:15:54 AM

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.  Furthermore, if it does
appear in such a draft I hope that it will be with reference to a
particular validation path.  Since one normally performs validation against
a specific context, only one trusted root is evaluated at a time.

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

[TG] My point is that the policy used to verify a signature is something
which the VERIFIER must decide on, rather than the signer, and signature
policies are things which you have defined as being specified by a signer
(see your own RFC 3126).  A verifier is as likely to know what an anchor is
as what a signature policy is.  If a signature policy includes a
specification of the trust anchors as well as of the verification mechanism
a user who does not know what a trust anchor is operating blindly in
accepting or choosing a signature policy.

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

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
certificats but are not cross-certificates. 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. 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.

I do not think so. See my first comment.

Regards,

Denis

>             Tom Gindin
>
> Denis Pinkas <[email-masked]>@mail.imc.org on 03/26/2002 12:11:50
PM
>
> Sent by:    [email-masked]
>
> To:    [email-masked]
> cc:    Carlisle Adams <[email-masked]>
> Subject:    Re: WG Last Call: Roadmap
>
> Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
>
> (snip)
> COMMENT 3. A sentence states: "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". Since an EE may trust more than one
Top
> CA, shouldn't we say:
>
> "However, to minimize confusion in this document, we elect to call this
> node
> a "Top CA," and reserve "Root CA" when there is a single CA directly
> trusted
> by the EE."
>
> COMMENT 4. On page 14. A clarification needs to be done between
> cross-certificates and CA certificates. The text currently states:
>
>    A cross-certificate is a PKC issued by one CA to another CA which
>    contains a public CA key associated with the private CA signature key
>    used for issuing PKCs. Typically, a cross-certificate is used to
>    allow client systems or end entities in one administrative domain to
>    communicate securely with client systems or end users in another
>    administrative domain. Use of a cross-certificate issued from CA_1 to
>    CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
>    which was issued by CA_2. Cross-certificates can also be issued from
>    one CA to another CA in the same administrative domain, if required.
>
> I would propose instead the following:
>
> " A CA certificate is a certificate in a hierarchy that is neither a
> self-signed certificate, nor an end-entity certificate. [2459bis] does
not
> make a difference between a CA certificate and a cross certificate since
it
> defines a cross-certificate as "a certificate issued by one CA to another
> CA". Some people in the WG believe that a cross certificate is a special
> kind of CA certificate. A cross certificate is issued by a CA under one
> Top CA for another CA under a different Top CA. CAs in the same hierarchy
> 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.
>
> Typically, a cross-certificate is used to allow client systems or end
> entities in one administrative domain to communicate securely with client
> systems or end users in another administrative domain. Use of a
> cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
> CA_1, to accept a PKC used by Bob, which was issued by CA_2.
> Cross-certificates can also be issued from one CA to another CA in the
same
> administrative domain, if required."
>
> COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
> identifying revoked PKCs that is signed by a CA and made freely available
> in a public repository."
>
> I would prefer to avoid to use "time-stamped" in that context and thus I
> would propose the following wording:
>
> "A CRL is a list that identifies the references of revoked PKCs. This
list
> contains a date of issue and is signed by a CA and made freely available
in
> a public repository."
>
> (snip)
>
> COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
> consider a single trust point:
>
> "  An important design decision is where a particular EE's trust point
>    is located (i.e., where is the EE's Root CA). There are a number of
>    models that have been developed and depending on the environment some
>    models may be more suited than others. The following provides some
>    background on the models."
>
> I would rather propose to change it into:
>
> " An important design decision is, for a given application, where the
> particular EE's trust points are located (i.e. what are the Top CAs).
> There are a number of models that have been developed and depending on
> the environment some models may be more suited than others. The following
> provides some background on the models."
>
> COMMENT 12. On page 49. Section 5.5 I would propose to add another model.
>
> 5.5.5 Validation policies
>
> 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).
> Regards,
> Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Apr 2002 18:32:41 +0200

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

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.

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

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

> Furthermore, if it does