Subject: Re: WG Last Call: Roadmap

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 18:15:54 +0200

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.

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

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: "todd glassey" <[email-masked]>
Date: Thu, 4 Apr 2002 09:33:29 -0800

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

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

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

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

> Some people in the WG believe
> 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