Subject: Strawpoll for DPD/DPV protocols

From: [email-masked]
Date: Tue, 21 Jan 2003 17:17:03 -0500

Folks,

As discussed at the last meeting and on the list, it is imperative that the 
PKIX working group progress a single DPD/DPV protocol.  Three strong proposals 
are on the table (listed in alphabetical order):

*  Certificate Validation Protocol (CVP), available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>;
*  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and
*  Simple Certificate Validation Protocol (SCVP), available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt>.

The working groups needs to make the difficult decision, and select the one 
and only PKIX protocol for DPD/DPV.  Our primary guide in the development of a 
DPD/DPV protocol is the requirements document RFC 3379.  Each of the editing 
teams has submitted a "compliance matrix" describing how their protocol 
satisfies requirements specified in 3379.  I want to encourage each of you to 
take this decision seriously.  The editors have all invested a great deal of 
time and effort in these documents, and we owe them that much.

I am asking that each of you review, at a minimum, the compliance matrix 
submitted by each team *before* voting.  The compliance matrix was a major 
pain for the editors and is our best yardstick for 3379 compliance.  Better 
yet, if you haven't reviewed the latest draft for one of the specifications, 
please take this opportunity to do so as well!  Informed voters make a better 
strawpoll result...

Since some of the compliance matrices were submitted recently, I would like to 
hold the voting open through Monday, January 27.  (Hopefully, this is enough 
time to get informed if you aren't already!)

To simplify the task for the co-chairs, I would appreciate if the Subject line 
could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx 
is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous 
strawpolls.)

Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 22 Jan 2003 09:42:46 +0100

Tim,

> <http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>;

This URL is wrong since it points to the next proposal. :-(
The right URL is: http://www.imc.org/draft-ietf-pkix-cvp

This is draft-ietf-pkix-cvp-02.txt from January 2003.
The draft has been updated to fully comply with the matrix.

> satisfies requirements specified in 3379.  

Tim, you got the CVP matrix since it was copied directly to you, but the 
mailing list did not get it. I have sent the URL provided by Paul, so that 
anybody can get it:

http://www.imc.org/ietf-pkix/CVP-Compliance.txt

 > I want to encourage each of you to

> submitted by each team *before* voting.  

Thank you Tim for the advise, since we already got three votes and it is 
doubtful whether the matrix for CVP has been reviewed *before* voting by 
these three voters.

That matrix highlights major benefits when compared with an alternative 
proposal.

I am wondering whether a strawpoll without any argument makes sense.

 > The compliance matrix was a major pain for the editors

Indeed.

> and is our best yardstick for 3379 compliance.  Better 

Given the size of the matrixes, I would think that one more week would be 
adequate.

> is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous 

This is too simplistic. Some text to support the vote should be included
(at least to prove that the matrixes and the drafts have been read). :-)

Denis

---

From: Tim Polk <[email-masked]>
Date: Wed, 22 Jan 2003 14:45:58 -0500

Folks,

It is time for this co-chair to eat some crow.

I totally blew it in my strawpoll message.  I missed Peter Sylvester's 
compliance matrix for DVCS (submitted on December 24). I was on vacation at 
the time, and didn't do a thorough job of catching up on the list.  Since I 
hadn't seen the compliance matrix, I did not include DVCS as a 
candidate.  I should have followed up with Peter to confirm that *before* 
sending the strawpoll message, but I did not.

DVCS is a fourth strong candidate for consideration in the the DPD/DPV 
strawpoll.  Please review RFC 3029 "Data Validation and Certification 
Server Protocols" and the compliance matrix as you prepare to vote.

If DVCS is your preferred protocol, please use the subject line 
STRAWPOLL:DVCS to vote for DVCS.

Now *I* have a choice to make - barbecue or teriyaki?

Thanks,

Tim Polk

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 23 Jan 2003 11:01:27 +0100 (CET)

In message <[email-masked]> on Tue, 21 Jan 2003 17:17:03 -0500, [email-masked] said:

wpolk> *  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
wpolk> drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and

I've a hard time finding a compliance matrix for this one.  Was one
ever submitted?  In any case, if there is one, I'd really appreciate
it if someone could send me a copy.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Jan 2003 11:50:12 +0100

Richard,

> In message <[email-masked]> on 
 > Tue, 21 Jan 2003 17:17:03 -0500, [email-masked] said:
> 
> DPV and DPD over OCSP, available at 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt> and

It was sent on January 15 by Mike Myers. It is copied below.

======================================================================

Topic 1: Basic Protocol

1. If the DPV server does not support the client requested  validation 
policy, then the DPV server MUST return an error. (4.1. Basic Protocol)

Errors are returned via RFC2560 encapsulation. An error state for
unsuportedPolicy can be folded into the ongoing work for OCSPv2.

2. If the DPV request does not specify a validation policy, the  server 
response MUST indicate the validation policy that was used.  (4.1. Basic 
Protocol)

"If a DPV request does not indicate a validation policy, DPV responders
SHALL include the DPV extended response OID and syntax in their
responses and SHALL identify in the policy field of that syntax the OID
identifying the policy in effect when the response was produced."

3. The protocol MUST allow the client to include these policy dependent 
parameters in the DPV request; however, it is expected that most clients 
will simply reference a validation policy for a given application or accept 
the DPV server's default validation policy. (4.1. Basic Protocol)

[For the candidate protocol, state the provisions it includes for such 
parameters.]

As it relates to DPV requests, the ExtendedOCSPRequest enables
specification of initialPolicySet, trustPoints and a token field related to 
the nature or reason for the query.

4. The DPV server MUST obtain revocation status information for the 
validation time in the client request. (4.1. Basic Protocol)

[a. Indicate how a conformant server for the candidate protocol deals  with 
other than "current time" validation requests.]

  [b. For the candidate protocol, indicate which revocation status methods a 
conformant server is required to support. A DPV server must support some 
revocation status methods, but the methods used by different CAs may differ, 
suggesting that a server needs to be prepared to deal with several such 
methods. A server may need to be configured to use specific methods for 
specific CAs. How does the candidate protocol accommodate this need?]

Need to address this.

5. If the revocation status information for the requested validation time is 
unavailable, then the DPV server MUST return a status indicating that the 
certificate is invalid.
Additional information about the reason for invalidity MAY also be provided. 
(4.1 Basic Protocol)

The invalid state is addressed.  Reasons are enabled.

6. The certificate to be validated MUST either be directly provided in the 
request or unambiguously referenced, such as the CA distinguished name, 
certificate serial number, and the hash of the certificate, like ESSCertID 
as defined in [ESS] or OtherSigningCertificate as defined in [ES-F]. (4.1 
Basic Protocol)

  [For the candidate protocol, specify which formats for certificate 
references MUST be supported by conformant clients and servers. The lists 
may differ for clients vs. servers, e.g., servers may bear the burden of 
having to accept a larger range of reference types, to ease the burden on 
clients.]

CertID syntax in [RFC2560] enables such a means.  Collateral WG efforts
on expanding this syntax will enable other mechanisms.

7. The DPV client MUST be able to provide to the validation server, 
associated with each certificate to be validated, useful certificates, as 
well as useful revocation information. (4.1 Basic Protocol)

[For the candidate protocol, indicate which forms of revocationstatus info a 
conformant client is allowed to provide, and whatforms of revocation status 
data a conformant server MUST beprepared to accept from a client.]

pathParams and revInfo are available in  DPVOptions.

3379 does not assert a requirement for normative specification of minimal
server-side requirements governing revocation data forms or formats.
Further WG consensus on this is point is anticipated.

8. The DPV server MUST have the certificate to be validated.  When the 
certificate is not provided in the request, the server MUST obtain the 
certificate and then verify that the certificate is indeed the one being 
unambiguous referenced by the client. (4.1 Basic Protocol)

[For the candidate protocol, specify what mechanisms a conformantserver MUST
implement in support of this requirement, e.g., retrieval of a certificate 
via LDAP queries.]

The cited text isinterpreted as an obvious fact.

3379 asserts no requirement for a normative specification of minimal
server-side certificate retrival mechanisms  Further WG consensus on this
is point is anticipated.
.

9. The DPV server MUST include either the certificate or an unambiguous 
reference to the certificate (in case of a CA key compromise) in the DPV 
response. (4.1 Basic Protocol)

Certificate reference is enabled via BasicOCSPResponse syntax of RFC2560.

10. The DPV response MUST indicate one of the following status alternatives:

    1.	the certificate is valid according to the validation policy.

    2.	the certificate is not valid according to the validation policy.

    3.	the validity of the certificate is unknown according to the 
validation policy.

    4.	the validity could not be determined due to an error.

  (source for 10: 4.1 Basic Protocol)

The valid, invalid and unknown states are addressed.  RFC2560 governs
production of errors.

11. When the certificate is not valid according to the validation policy, 
then the reason
MUST also be indicated.  Invalidity reasons include:

    1.	the DPV server cannot determine the validity of the certificate 
because a certification path cannot be constructed.

    2.	the DPV server successfully constructed a certification path,    but 
it was not valid according to the validation algorithm in  [PKIX-1].

    3.	the certificate is not valid at this time.  If another request could 
be made later on, the certificate could possibly be determined as valid. 
This condition may occur before a certificate validity period has begun or 
while a certificate is suspended.  (Source for 11: 4.1 Basic Protocol)

[For the candidate protocol, indicate what if any, other invalidity reasons 
are reportable by a conformant server.]

The OCTET STRING Reasons associated with the invalid state enables
responders to indicate reasons to requestors.  On the basis of prior
experience, it is anticipated that: 1) the full spectrum of such reasons may
be broad, owing to mission-specific needs; and yet 2) there might be a
core set worthy of standardization but that dialog has yet to occur.

12. The protocol MUST prevent replay attacks, and the replay prevention 
mechanism employed by the protocol MUST NOT rely on synchronized clocks. 
(4.1 Basic Protocol)

[For the candidate protocol, describe the means by which conformant clients 
and servers detect and reject replay attacks.]

RFC2560 governs the use of replay detection via the use of nonces.

13. The DPV request MUST allow the client to request that the server include 
in its response additional information which will allow relying parties not 
trusting the DPV server to be confident that the certificate validation has 
correctly been performed.

[…]When the certificate is valid according to the validation policy, the 
server MUST, upon request, include that information in the response. 
However, the server MAY omit that information when the certificate is 
invalid or when it cannot determine the validity. (4.1 Basic Protocol)

[For the candidate protocol, specify the additional information that a 
conformant server MUST be able to provide and indicate how the set of 
information to be returned is determined, e.g., if it may vary depending on 
the client or other parameters.]

Requestors can ask responders to return one or more of: certification
path; revocation information; a time stamp; or policy identifier

The DPV/DPD requirements RFC does not assert a requirement for
normative specification of minimal server-side suypport for additional
information  It was assumed this is a deployment-specific issue.

Return of validation policy OID is enabled.

14. The DPV server MUST be able, upon request, copy a text field  provided 
by the client into the DPV response. (4.1 Basic Protocol)

The token field in Parameters syntax is defined for this purpose.

15. The DPV response MUST be bound to the DPV request so that the client can 
be sure that all the parameters from the request have been taken into 
consideration by the DPV server to build the response.  This can be 
accomplished by including a one-way hash of the request in the  response.

[For the candidate protocol, describe how this binding is effected.]

"If a value for requestExtensions is present in the DPV request  (thus
indicating the presence of requestor-specified parameters),  responders
shall perform a hash across this value using the SHA-1 algorithm AND
include this resulting value in the paramHash field."

In some environments it may be necessary to present only a DPV response to 
another relying party without the corresponding request. In this case the 
response MUST be self contained.  This  can be accomplished by repeating 
only the important components  from the request in the response. (4.1 Basic 
Protocol)

"If the returnReq bit is set, responders SHALL return in reqContents field
the contents of the received DPVOptions . . ."

16. For the client to be confident that the certificate validation was 
handled by the expected DPV server, the DPV response MUST be authenticated, 
unless an error is reported (such as a badly formatted request or unknown 
validation policy).

[For the candidate protocol, specify the response message authentication 
mechanisms that a conformant server MUST support, and those that a 
conformant client MUST support.
Note that clients might be required to support fewer mechanisms, or might be 
required to support only one mechanism from a set, while a server might be 
required to support all of the mechanisms in the set, e.g., as a means of 
ensuring interoperation.]

For the client to be able prove to a third party that trusts the same DPV 
server that the certificate validation was handled correctly, the DPV 
response MUST be digitally signed, unless an error is reported. The DPV 
server's certificate MUST authenticate the DPV server. (4.1 Basic Protocol)

"In instances where it is important to authenticate the identity of a
responder prior to acceptance of its response, lower layer security
protocols could be used to establish the identity of the intended responder.
Note that authoritative DPV responses are required to be digitally signed.
Thus, to the extent the identity contained in the certificate used to 
validate a response is an acceptable form of response authentication, this 
method may suffice."

17. The DPV server MAY require client authentication, therefore, the DPV 
request MUST be able to be authenticated. (4.1 Basic Protocol)

[For the candidate protocol, describe the request message authentication 
mechanisms that a conformant server MUST support, and those that a 
conformant client MUST support, to ensure a minimal level of 
interoperability. Note that clients might be required to support
fewer mechanisms, or might be required to support only one mechanism from a 
set, while a server might be required to support all of the mechanisms in 
the set, e.g., as a means of ensuring interoperation.]

See above.

18. When the DPV request is authenticated, the client SHOULD be able to 
include a client identifier in the request for the DPV server to copy into 
the response.  Mechanisms for matching this identifier with the 
authenticated identity depends on local DPV server conditions and/or the 
validation policy.  The DPV server MAY choose to blindly copy
the identifier, omit the identifier, or return an error response. (4.1 Basic 
Protocol)

[For the candidate protocol, describe provisions for confidentiality, if any.]

"If requestorName is included TBSRequest element, responders SHALL
include this value in the reqID field of  ExtendedOCSPResponse.  Where
client authentication is important to the responder's policy (e.g.
authorization to access the service), lower-layer protocol  MAY be used to
establish this authentication.  If used, responders SHOULD copy the
client-auth identity into the reqID field."

Topic 2: Relay and Redirection

19. Protocols designed to satisfy these requirements MAY include optional 
fields and/or extensions to support relaying, re-direction or multicasting. 
  […]  If the protocol supports such features, the protocol MUST include 
provisions for DPV clients and DPV servers that do not support such 
features, allowing them to conform to the basic set of
requirements. (4.2. Relaying, Re-direction and Multicasting)

[For the candidate protocol, describe any relay, referral, or multicasting 
facilities required of conformant server.]

No specific mechanisms are defined.  Current OCSP deployment practice
has shown that relaying and referral needs can be addressed.

20. When a server supports a relay mechanism, a mechanism to detect loops or 
repetition MUST be provided. (4.2. Relaying, Re-direction and Multicasting)

See above re: 19.

21. When a protocol provides the capability for a DPV server to redirect a 
request to another DPV server (that is, the protocol chooses to provide a 
referral mechanism), a mechanism to provide information to be used for the 
re-direction SHOULD be supported. If such re-direction information is sent 
back to clients, then the protocol MUST allow conforming clients to ignore 
it. (4.2. Relaying, Re-direction and Multicasting)

[For the candidate protocol, describe what strategy is employed to deal with 
redirection by a conformant server and what redirectionfeatures are mandated 
for a conformant client.]

See above re: 19.

22. Optional parameters in the protocol request and/or response MAY be 
provide support for relaying, re-direction or multicasting.  DPV clients 
that ignore any such optional parameters MUST be able to use the DPV 
service.  DPV servers that ignore any such optional parameters MUST still be 
able to offer the DPV service, although they might not
be able to overcome the limitations imposed by the network topology.  In 
this way, protocol implementers do not need to understand the syntax or 
semantics of any such optional parameters. (4.2. Relaying, Re-direction and 
Multicasting)

See above re: 19.

Topic 3: DPD Requirements

23. Clients MUST be able to specify whether they want, in addition to the 
certification path, the revocation information associated with the path, for 
the end-entity certificate, for the CA certificates, or for both. (5. 
Delegated Path Discovery Protocol)

[For the candidate protocol, specify what revocation status data types MUST be
supported by a conformant server.]

Requestors are able specify via the Flags field of ExtendedOCSPRequest
whether they wish to receive EE and/or CA revocation Information.  The
ExtendedOCSPResponse syntax and its DPD usage specification further
enables clients to request CRLs and/or OCSP.

24. If the DPD server does not support the client requested path discovery 
policy, the DPD server MUST return an error. (5. Delegated Path Discovery 
Protocol)

Errors are reported via the RFC2560 envelope.

25. The DPD request MUST allow more elaborated path discovery policies to be
referenced. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify the parameters for path discovery that 
a conformant server MUST support, i.e., the minimum path discovery policy 
supported, and specify what optional path discovery parameters a server 
SHOULD/MAY support.]

The ExtendedOCSPRequest syntax and its DPD usage specification enables this.

26. If the trust anchor is a self-signed certificate, that self-signed 
certificate MUST NOT be included.  In addition, if requested, the revocation 
information associated with each  certificate in the path MUST also be 
returned. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify the types of revocation status data 
that a conformant server MUST support.]

"[If] the trust anchor is a self-signed certificate . . . that certificate 
SHALL NOT be included in the path."

27. By default, the DPD server MUST return a single certification path for 
each end-entity certificate in the DPD request. (5. Delegated Path Discovery 
Protocol)

"Responders aware of multiple candidate paths that satisfy requestor-
specified parameters (if any) SHALL include in their responses the lesser
of the number of qualified paths or the number of paths specified by the
requestor in numPaths.  If the requestor did not specify numPaths then, by
default, the responder MUST return a single certification path for each
end-entity certificate in the DPD request."

28. Therefore, the DPD client MUST have a means of obtaining more than one
certification path for each end-entity certificate in the DPD request.  At 
the same time, the mechanism for obtaining additional certification paths 
MUST NOT impose protocol state on the DPD server. (5. Delegated Path 
Discovery Protocol)

[For the candidate protocol, provide a state machine description of DPD 
operation, to demonstrate that this requirement is met.]

See above re: 27.

29. Path discovery MUST be performed according to the path discovery policy. 
  The DPD response MUST indicate one of the following status alternatives:

    1.	one or more certification paths was found according to the  path 
discovery policy, with all of the requested revocation information present.

    2.	one or more certification paths was found according to the  path 
discovery policy, with a subset of the requested revocation information present.

    3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation  information present.

    4.	no certification path was found according to the path  discovery policy.

    5.	path construction could not be performed due to an error.

(Source for 29: 5. Delegated Path Discovery Protocol)

"Responders SHALL develop a path or paths correspondent to a
requestor-specified path discovery policy when such is indicated in the
request."

"Requestors can derive these states from a DPD response as follows.
Errors are reported as OCSPResponseStatus (see [RFC2560]) in which
case no path data is present in the response.  A value of successful in
OCSPResponseStatus indicates the presence of pathInfo in
ExtendedOCSPResponse.  This value may be NULL, indicating that no
paths were discovered.  Requestors that did not request revInfo will not
receive revInfo. Else each certificate in each path returned via the
pathInfo structure may or may not have revInfo associated with it.
Absence of revInfo for a given certificate in the pathInfo structure enables
requestor determination of the first three states noted above."

30.   For the client to be confident that all of the elements from the 
response originate from the expected DPD server, an authenticated response 
MAY be required.  For example, the server might sign  the response or data 
authentication might also be achieved using a lower-layer security protocol. 
(5. Delegated Path Discovery  Protocol)

[For the candidate protocol, specify whether conformant servers MUST be 
capable of generating authenticated responses, what authentication 
mechanisms they MUST support, and what authentication mechanisms conformant 
clients MUST support. Note that clients might be required to support fewer 
mechanisms, or might be required to support only one mechanism from a set, 
while a server might be required to support all of the mechanisms in the 
set, e.g., as a means of ensuring interoperation.]

RFC2560 enables responder signatures.

31. The DPD server MAY require client authentication, allowing the DPD 
request MUST to be authenticated. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify whether conformant servers MUST be 
capable of authenticating requests, what authentication mechanisms they MUST 
support, and what authentication mechanisms conformant clients MUST support. 
Note that clients might be required to support fewer mechanisms, or might be 
required to support only one mechanism from a set, while a server might be 
required to support all of the mechanisms in the set, e.g., as a means of 
ensuring interoperation..]

"Where client authentication is important to the responder's policy (e.g.
authorization to access the service), a lower-layer protocol may be used to
establish this authentication.  If used, responders SHOULD copy the
client-auth identity into the reqID field of ExtendedOCSPResponse."

32. Using a separate request/response pair, the DPV or DPD client MUST be 
able to obtain references for the default policy or for all  of the policies 
supported by the server. (6. DPV and DPD Policy Query)

Policy Discovery Protocol (PDP) is not addressed.

33. In order to succeed, one valid certification path (none of the 
certificates in the path are expired or revoked) MUST be found between an 
end-entity certificate and a trust anchor and all constraints that apply to 
the certification path MUST be verified. (7. Validation Policy)

34. The validation policy MUST specify the source of revocation information:

    1.	full CRLs (or full Authority Revocation Lists) have to be collected.

    2.	OCSP responses, using [OCSP], have to be collected.

    3.	delta CRLs and the relevant associated full CRLs (or full  Authority 
Revocation Lists) are to be collected.

    4.	any available revocation information has to be collected.

    5.	no revocation information need be collected.

(Source for 34: 7.3. Revocation Requirements)

Policy Discovery Protocol (PDP) is not addressed.

35. The validation policy MUST specify the source of revocation information:

    - full CRLs (or full Authority Revocation Lists) have to be collected.

    - OCSP responses, using [OCSP], have to be collected.

    - delta CRLs and the relevant associated full CRLs (or full Authority 
Revocation Lists) are to be collected.

    - any available revocation information has to be collected.

    - no revocation information need be collected.

(source for 35: 7. Validation Policy)

[For the candidate protocol, describe the path validation and path discovery 
policy parameters that a conformant server MUST or  SHOULD support, e.g., 
trust anchor names, keys, name  constraints and policy constraints for trust 
anchors, path depth limits, key usage constraints, extended key usage 
constraints,  required/allowed revocation status data types, etc.]

Policy Discovery Protocol (PDP) is not addressed.

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 23 Jan 2003 16:58:41 -0500

> (at least to prove that the matrixes and the drafts have been read). :-)

I have to agree with Denis here.  A WG process based on the number of warm
bodies submitting rationale-less votes does not inspire confidence.  If
each of the voters had a history of contributing to the discussion, the straw
poll would have meaning.  With neither a history of discussion nor a rationale
attached to the vote, it has none.

Dave