Subject: Re: Candidate for moving OCSP to a Draft Standard

From: "David P. Kemp" <[email-masked]>
Date: Tue, 19 Mar 2002 16:15:51 -0500

Ambarish,

Section 3.1 of RFC 2560 (unchanged in draft -03) includes the following:

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

This requirement prohibits local elements (i.e. LAN administrators) from
operating Authorized Responders, because every LAN URI would have to be
included in every EE certificate.  There are potentially hundreds or
thousands of local elements that may wish to operate Authorized Responders
(although I expect that isn't part of your business model :-), and it
would be completely impractical to list them all in each EE certificate.

From a security perspective, the thing that distinguishes a Trusted
Responder from an Authorized Responder is the existence of the delegation
certificate described in section 2.6.  AIA is an operational convenience
that allows clients to find responders without needing additional
configuration information.  It (AIA) is not security-critical.

I request that the MUST in section 3.1 be changed to MAY.  Leaving it
at MUST imposes a severe and unnecessary restriction on the possible
operational scenarios.

Regards,
Dave

Ambarish Malpani wrote:
> 
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
> 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
> 
> I hope we can get to the Draft Standard state before this IETF.
> 
> Regards,
> Ambarish

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 19 Mar 2002 15:31:43 -0800

Dave,

Is your issue one of deployment or code-level implementation?
Because my intent was to drive into existence functionality that
MAY be deployed on an as-needed basis.  Note the text "provide
for".  That doesn't mean you have to use that functionality.  It
means that the server you use MUST be capable of such.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David P. Kemp
> Sent: Tuesday, March 19, 2002 1:16 PM
> To: [email-masked]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Ambarish,
>

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 20 Mar 2002 08:51:47 -0500

Mike and Ambarish,

I agree with the MUST as a code-level requirement, I am concerned
only about deployment.  To avoid potential confusion, how about
using the "capable" text in the standard:

    CAs that support an OCSP service, either hosted locally or
    provided by an Authorized Responder, MUST be capable of
    including a value for a uniformResourceIndicator ...

Thanks for the clarification,
Dave

---

From: [email-masked]
Date: Wed, 20 Mar 2002 09:46:46 -0500 (EST)

This message initiates a two week Working Group Last Call for "Internet X.509 
Public Key Infrastructure: Roadmap". The document is available at

     http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-07.txt

Assuming successful completion of Last Call, the document will be forwarded for 
consideration as an Informational track RFC.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Mar 2002 18:11:50 +0100

Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt

 
> consideration as an Informational track RFC.

First of all. It is a very good and useful document. Nevertheless, a few
comments.

COMMENT 1. On page 1: 

"This draft is being discussed on the 'ietf-smime' mailing list. 
To subscribe, send a message to [email-masked] with 
the single word subscribe in the body of the message."

Now I understand why we got no comment on the PKIX mailing list. 
All comments have certainly been addressed to the SMIME mailing list !!!

:-)

COMMENT 2. Replace "at" by "prior" in expressions referring to Time-Stamping
in two sentences: "at an instant in time" (page 5) and "at a given time"
(page 7).

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

COMMENT 6. On page 22. Correct a typo. Change "ôRepresentation" by
"Representation".

COMMENT 7. On page 22. Correct a typo. Change "Certificates.ö" by
"Certificates." 

COMMENT 8. On page 22. Correct a typo. Change "fro" by "from"

COMMENT 9. On page 22. Due to a very recent change of scope of the PI
document replace "individual" by "entity".

This leads to the following:

     This document defines a new form of name, the 
     permanent identifier, which is a name assigned by an organization, 
     unique within that organization, that singles out a particular 
     entity from all other entities. The permanent identifier is 
     an optional feature that may be used by a CA to indicate that the 
     certificate relates to the same entity even if the name or the 
     affiliation of that entity has changed. The permanent 
     identifier is important in the context of access control and of 
     non-repudiation.

COMMENT 10. On page 28. The story about patents on TSP is currently
described as follows:

   "At the Minneapolis IETF meeting, it was disclosed that the materials 
   covered in [TSP] draft may be covered by patent(s). Use of the 
   material covered by the patent(s) in question has not be granted by 
   the patent holder. Thus, anyone interested in implementing the PKIX 
   [TSP] draft must be aware of this intellectual property issue. "

Which IETF meeting in Minneapolis, since we have had three meetings in that
location ? Anyway, the description does not capture what happened with
Surety and Entrust. During the last IETF 2002 meeting in Minneapolis, I have
asked Carlisle to provide a text replacement.

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: "Sean P. Turner" <[email-masked]>
Date: Tue, 26 Mar 2002 18:32:04 -0500

Denis,

All of your comments are accepted unaltered.  BTW - it was the IETF44 where the TSP
IP issues were addressed (according to the minutes).

spt