Subject: RE: DPV and DPD

From: Michael Zolotarev <[email-masked]>
Date: Sat, 14 Jul 2001 14:15:21 +1000

Denis,

<<To sweeten up your vacations>> I've given the document a very quick read
through. Just the DPV part of it to start with.
And of course I'm avoiding any comments about the motivations and politics
matters, at that stage.

P1. [3]. "A trust ancor is defined.. " The sentence is unclear. Cannot even
think of suggesting something else.
P3. [5]. Validation time is missing in the Request data list (though present
in DPVRequest).
P3 or 4. [5] is followed by [5.2]. Where is [5.1]?

ValPolicyRef. Suggest making valPolicyHash optional. ( Yes, I know where it
comes from and I remember the discussion on ETSI list. Never liked it. )

P7. [5.2.2] DPVResponse. pathReferences must be explicitely tagged. Both
tbsResponse and pathReferences are SEQUENCE. Think about what happens if
optionalSignature is not there.

DPVResponse. The signature is marked as optional, but it contradicts to the
statement futher down in the same paragraph: "The response must be integrity
protected...". Suggest changing to "The *valid* response must be integrity
protected...".

TBSResponse. Why is the certs field tagged?

DPVResponseData. You have two optional OCTET STRING elements one following
another. Tagging is necessary.

RevokedInfo. Why bother adding revokedCert in there? It is the same as the
certProcessed. 

P9. Last sentence before [6]. requestExtensions. Must be responseExtensions.

Regards
Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, 13 July 2001 1:52
> To: pkix
> Subject: DPV and DPD
> 
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. A URL for this Internet-Draft is:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-00.txt
> 
> In the advertisement, the abstract has been cut down. The 
> full abstract 
> is the following:
> 
> This document specifies two protocols. The first one, called 
> Delegated 
> Path Validation (DPV) can be used to fully delegate a path validation 
> processing to an DPV server, according to a set of rules called a 
> validation policy. 
> 
> The second one, called Delegated Path Discovery (DPD) can be used to 
> obtain from a DPD server all the information needed (e.g. leaf 
> certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses) 
> to locally validate a certificate according to a set of rules called 
> a path validation criteria. This provides a single protocol 
> to collect 
> at one time all data elements that normally require different 
> protocols.
> 
> It also defines an optional protocol allowing to define the set of 
> rules to validate a certificate or to build a path for a certificate.
> 
> 
> Since I am going on vacations on Friday July 13 th and will be back
> the week prior to the next IETF meeting in London (that I 
> will attend) 
> this does not give me much time to discuss it. A few hints:
> 
> At the last meeting, OCSPv2 was discussed quite heavily. I 
> still find that
> the approach of trying to extend OCSPv1 to support both DPV 
> and DPD is not
> the right approach. I also believe that the services, as 
> being described, 
> do not fullfill some objectives.
> 
> Instead of trying to make corrections that would have been 
> quite major, 
> I have written a new draft. It takes some inputs from the 
> work that has been
> done in the S/MIME WG and re-uses some of the ASN1 structures 
> that have been
> defined in a document that should be published soon (?) (i.e. 
> when the TSP 
> document is published). The document is currently referenced 
> as "Electronic 
> Signature Formats for long term electronic signature" and is 
> available at:
> http://www.imc.org/draft-ietf-smime-esformats.
> 
> I have prepared some slides to present the document at the 
> London meeting.
> 
> Denis
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.