RFC 3379 compliance matrix

[Tim Polk <tim.polk@xxxxxxxx>]

Dear DPD/DPV editors,

You will find attached to this message the long awaited compliance matrix 
for DPD/DPV protocols.  The "matrix" consists of 35 requirements statements 
extracted from RFC 3379.  Each statement includes a reference to the 
relevant section of the RFC.  Most include directions from the chairs to 
the editors that elaborate on the type(s) of information we are looking 
for.  Directions to the editors are in brackets.

To have your respective documents considered for selection as the PKIX 
DPD/DPV protocol, please complete the attached matrix describing how your 
protocol satisfies the requirements.  Please respond to each requirement 
in-line, so that reviewers will be able to easily compare the responses.

In light of the holiday season, please complete the document and submit to 
the PKIX list by January 8.  We will allow a week for discussion and hold 
the straw poll January 16 and 17.

Thanks,

Steve Kent
Tim Polk

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)

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)

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.]

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?]

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)

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.] 

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 revocation
status info a conformant client is allowed to provide, and what
forms of revocation status data a conformant server MUST be
prepared to accept from a client.]

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 conformant
server MUST implement in support of this requirement, e.g.,
retrieval of a certificate via LDAP queries.]

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) 

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)

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.]

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.]

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.]

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)

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.]

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) 

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)

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.]

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.]

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.]

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)

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 redirection
features are mandated for a conformant client.]

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) 

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.]

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)

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.]

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.]

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)

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.]

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) 

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.]

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..]

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)

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)

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.]