Subject: Re: WG Last Call: Roadmap

From: Peter Sylvester <[email-masked]>
Date: Wed, 20 Mar 2002 17:43:50 +0100 (MET)

The text contains:

" At the Minneapolis IETF meeting, it was disclosed that the materials "

It would be nice to indicate the meeting number.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 27 Mar 2002 11:02:11 +0100 (MET)

> 
> All of your comments are accepted unaltered.  BTW - it was the IETF44 where the TSP
> IP issues were addressed (according to the minutes).
> 
This reminds me that I have send a comment privately: 

I propose a replacement of the text concerning dvcs composed
from the actual content of the RFC. 

Thanks for consideration.
Peter

  - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 
     Certification Server Protocols (RFC 3029) 
    
   DESCRIPTION:

   This document describes a general Data Validation and Certification
   Server (DVCS) and the protocols to be used when communicating with
   it.  The Data Validation and Certification Server is a Trusted Third
   Party (TTP) that can be used as one component in building reliable
   non-repudiation services.

   Useful Data Validation and Certification Server responsibilities in a
   PKI are to assert the validity of signed documents, public key
   certificates, and the possession or existence of data.

   As a result of the validation, a DVCS generates a Data Validation
   Certificate (DVC).  The data validation certificate can be used for
   constructing evidence of non-repudiation relating to the validity and
   correctness of an entity's claim to possess data, the validity and
   revocation status of an entity's public key certificate and the 
   validity and correctness of a digitally signed document.

   The presence of a data validation certificate supports
   non-repudiation by providing evidence that a digitally signed
   document or public key certificate was valid at the time indicated in
   the DVC.

   A DVC validating a public key certificate can for example be used
   even after the public key certificate expires and its revocation
   information is no longer or not easily available.  Determining the
   validity of a DVC is assumed to be a simpler task, for example, if
   the population of DVCS is significantly smaller than the population
   of public key certificate owners.

   The production of a data validation certificate in response to a
   signed request for validation of a signed document or public key
   certificate also provides evidence that due diligence was performed
   by the requester in validating a digital signature or public key
   certificate.

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 29 Mar 2002 11:51:44 -0500

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.  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.
      In your comment 5 (on page 15), replace "date of issue" by "date and
time of issue".
      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.
      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".
      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.

            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