OCSP for DPV and DPD rqmts compliance

["Michael Myers" <myers@xxxxxxxxxxxxx>]

All,

Apologies for being a bit late on this.  Compliance statements
per Tim's direction attached.

Mike

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.