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

From: Peter Sylvester <[email-masked]>
Date: Tue, 2 Apr 2002 15:25:39 +0200 (MET DST)

> 
> COMMENT 5: No authentication of the server prior to the sending of the
> request (not done with similar protocols). 
> 
Denis, I think that I may have badly stated the requirement. I 
assume an online connection *and* confidentiality via TLS
done at the transport layer. In this case, confidentiality
would be somewhat meaningless if you don't authenticate the 
server.  Your remark is correct if you think about encryption 
with email, but then you assume that only the server can decrypt,
thus you still have server authentication. 

What similar protocol do you have in mind? (OCSP)?

> COMMENT 6: Confidentiality done at transport level.

Ok, but it is not mentioned in the text. If
properly stated, it resolves COMMENT 5. 

>  
> COMMENT 8: Relaying not supported by the protocol.
>
This is a pity: This was omitted in OCSP, and the risk
of endless loops of two OCSP servers talking to each other
are definitely there. 
Relaying a request to another service is a requirement,
at least in the same way as it is for OCSP. 

But there are two issues:

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.  

peter

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 17:07:25 +0200

Peter,

> thus you still have server authentication.

If a server can decrypt, this does not authenticate the server to the
requester.
 
> What similar protocol do you have in mind? (OCSP)?

For example.

> properly stated, it resolves COMMENT 5.

Confidentiality is not a requirement for this protocol. 
Since this document lists requirements, non-requirements are not listed.
Nevertheless, in order to be very explicit on that point (and because a new
draft will need to be edited for some other comments anyway), it is proposed
to add the following sentence at the end of sections 4 and 5:

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

> at least in the same way as it is for OCSP.

These two sentences are self-contradictory: 

 - "omitted in OCSP" and 
 - "in the same way as it is for OCSP". 

There is no relaying in OCSP.

> In all such cases there is a danger (like in OCSP)

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.

Denis