Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt

From: Denis Pinkas <[email-masked]>
Date: Tue, 02 Apr 2002 11:23:53 +0200

Mike,

> Tim,
> 
> Two working days seems a bit tight given the breadth of
> comments.  Given that constraint, silence may not necessarily
> concurrence.  It could very well be the effects of our day jobs.
> But that said, I'll see what I can do regarding those comments I
> made.

Since you did not attended the Minneapolis meeting, in order to help you,
here is the disposition of comments that has been presented, with comments
19, 23 and 25 updated.

Denis

Disposition of comments

COMMENT 1: Hash of the request in signed response or important elements of
the request: responses need to include binding to the certificate from the
request.

COMMENT 2: random number repeated in the response.

COMMENT 3: no algorithm requirements.

COMMENT 4: PDP (Policy Definition Requ.) will be in a different document.

COMMENT 5: No authentication of the server prior to the sending of the
request (not done with similar protocols). 

COMMENT 6: Confidentiality done at transport level.

COMMENT 7: Requests shall be able to be authenticated.

COMMENT 8: Relaying not supported by the protocol.

COMMENT 9: Responses are definitive. No later update. 

COMMENT 10: Meaning of time T. It is the time for which the revocation
status is requested by the client. 

COMMENT 11:  For DPV, a reference to a validation policy is mandatory. 
Somevalidation policies may allow for a few user-defined parameters.

COMMENT 12: the server must have the full certificate. In the response
either the full certificate or an unambiguous reference of the certificate
is needed (in case of a CA key compromise). 

COMMENT 13: The client should must verify that the policy used by the server
is appropriate (moved in the security consideration section)

COMMENT 14: Number of states to be returned: two (Yes/No). A reason for the
No has to be returned.  

COMMENT 15: See comment 1.

COMMENT 16: Relates to comment 10. Cautionary period moved in security
consideration section.

COMMENT 17: Idem 16.

COMMENT 18: DSV mention deleted. A DSV Requ. draft will be progressed a soon
as this document is sent to the IESG.

COMMENT 19: Accepted. The paragraph has been deleted.

COMMENTS 20, 21, 22: Editorial. OK.

COMMENT 23 : Accepted. I have added an example for the policy specific
parameters: "e.g. root self-signed certificates".

COMMENT 24 : Editorial. OK.

COMMENT 25 : Since the text will move in a new document about PDP, the
comment is no more relevant to this document.

COMMENT 26 : "The protocol SHALL allow clients to obtain the references for
the default or for all of the policies supported by the server by using an
additional request/response pair".

COMMENT 27 : Addition of Policy Retrieval Protocol (PRP) requirements in the
PDP document (no more relevant for this document).

Note: The requirements only address Public Key Certificates (PKCs).
Attribute Certificates are outside the scope. 
 
> Mike
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Tim Polk
> > Sent: Friday, March 29, 2002 2:55 PM
> > To: [email-masked]
> > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> >
> > Folks,
> >
> > The editors have informed me that they believe the
> > -03 draft satisfies all
> > WG Last Call comments and meets the criteria of rough
> > consesnsus. My review
> > agrees with their position, and I would like to ship
> > the document to the
> > ADs as soon as possible.
> >
> > If you have a dog in this fight, *please review the
> > specification by
> > Tuesday COB.*  If I do not see any traffic on the
> > list stating that
> > unresolved comments remain, I will forward the
> > document to the ADs
> > Wednesday morning.
> >
> > Thanks,
> >
> > Tim Polk
> >
> > At 07:03 AM 3/29/02 -0500, you wrote:
> > >A New Internet-Draft is available from the on-line
> > Internet-Drafts
> > >directories.
> > >This draft is a work item of the Public-Key
> > Infrastructure (X.509) Working
> > >Group of the IETF.
> > >
> > >         Title           : Delegated Path Validation
> > and Delegated Path
> > > Discovery
> > >                           Protocol Requirements
> > (DPV&DPD-REQ)
> > >         Author(s)       : D. Pinkas, R. Housley
> > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > >         Pages           : 11
> > >         Date            : 28-Mar-02
> > >
> > >This document specifies the requirements for
> > Delegated Path Validation
> > >(DPV) and Delegated Path Discovery (DPD) for Public
> > Key Certificates.
> > >It also specifies the requirements for DPV and DPD
> > policy management.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-d
> > pv-dpd-req-03.txt
> > >
> > >To remove yourself from the IETF Announcement list,
> > send a message to
> > >ietf-announce-request with the word unsubscribe in
> > the body of the message.
> > >
> > >Internet-Drafts are also available by anonymous FTP.
> > Login with the username
> > >"anonymous" and a password of your e-mail address.
> > After logging in,
> > >type "cd internet-drafts" and then
> > >         "get draft-ietf-pkix-dpv-dpd-req-03.txt".
> > >
> > >A list of Internet-Drafts directories can be found in
> > >http://www.ietf.org/shadow.html
> > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > >Internet-Drafts can also be obtained by e-mail.
> > >
> > >Send a message to:
> > >         [email-masked].
> > >In the body type:
> > >         "FILE
> > /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt".
> > >
> > >NOTE:   The mail server at ietf.org can return the
> > document in
> > >         MIME-encoded form by using the "mpack"
> > utility.  To use this
> > >         feature, insert the command "ENCODING mime"
> > before the "FILE"
> > >         command.  To decode the response(s), you
> > will need "munpack" or
> > >         a MIME-compliant mail reader.  Different
> > MIME-compliant mail readers
> > >         exhibit different behavior, especially when
> > dealing with
> > >         "multipart" MIME messages (i.e. documents
> > which have been split
> > >         up into multiple messages), so check your
> > local documentation on
> > >         how to manipulate these messages.
> > >
> > >
> > >Below is the data which will enable a MIME compliant
> > mail reader
> > >implementation to automatically retrieve the ASCII
> > version of the
> > >Internet-Draft.
> > >Content-Type: text/plain
> > >Content-ID:     <[email-masked]>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-d
> pv-dpd-req-03.txt>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Apr 2002 17:22:33 +0200 (MET DST)

> 
> Peter:
> 
> Would you be happy if the client and server identities were optional?

I never had anything else in mind: What about:

The protocol MUST provide a means to allow a client and a server
to indicate the participating entities (depending on policy
or application context).

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Apr 2002 17:37:53 +0200 (MET DST)

Thnaks for adding the following: I suggest some small wording change:

> 
> "There are no specific requirements for confidentiality at the protocol 
> level. Confidentiality may be achieved at the transport level."
I suggest: 

  "There are no specific requirements for support of confidentiality at the protocol 
  level. Confidentiality may be achieved at the transport level."

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Apr 2002 19:14:46 +0200 (MET DST)

About 'invisible realying':

> > Why do you think that a DPV response from a server MUST NOT
> > contain a DPV response from another server, while on the other
> > hand it is provided that the server returns all information
> > concerning the certification path, an revocation information.
> > What does make DPV responses so different from OCSP reponses
> > that they would create either additional complexity or harm.
> > 
> > An end user only communicates with his local company
> > service. The company knows which external CAs can be
> > trusted, and which service can be contacted.
> > You already allow to contact OCSP services in this
> > way. Where is the difference between DPV and OCSP?
> > 
> > It may be desirable that an end user may not
> > directly interface with a remote DPV and needs an
> > intermediate 'anonymizer' or 'authorized relay'.
> > 
> > In all such cases there is a danger (like in OCSP)
> > for endless loops.
> 
> There is no such a danger: the request is sent to one server and must come
> back from that same server. If the server uses relaying in the back ground
> to fulfill the service, then this is not visible from the requester. The
> final response from a DPV server is signed by the server that received the
> original request. Relaying is not supported by the protocol.

- You accept now that there is relaying of dpv requests is possible.  

  Assume that two companies operate a DPV service, and in 
  order to validate a certificat of the other company, a request is relayed
  (as you suggest) in a back ground way. A simple configuration
  error in one of the servers and the request gets relayed back etc.

- Russ answered my request for an optional inclusion of the identities
participating in the transaction. having this I think this is sufficient
to address the loop problem. 

But: You have not answered my question why you believe that a inclusion
of another dpv response in a response is a harmful thing. 
I believe that there are scenarios where it is useful that relaying be
made visible.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Apr 2002 19:18:56 +0200 (MET DST)

> 
> It is proposed to add after the current last paragraph from section 4: 
> 
> "When the request is authenticated, the requestor shall have the possibility
> to have its identifier included or not in the response."

Identification and Authentication are different things. 

I have proposed in a different mail to Russ: 

  The protocol MUST provide a means to allow a client and a server
  to indicate the participating entities. 

I correct '... to indicate the identities of the entities participating in
the transction'. 

and one may add "(depending on policy or application context)". 

> Since relaying is not supported (see the response to your other e-mail),
> there is no difference between "for whom the response has been made" and
> "who has made the response".

'For whom' indicated the requester(s). I agree that there may
be a language problem. I did not mention 'for whom' as a synomym
of 'on behalf of'. 

Peter