Subject: Rating of the "DPV and DPD over OCSP" Compliance Matrix

From: Denis Pinkas <[email-masked]>
Date: Mon, 27 Jan 2003 11:17:19 +0100

Rating of the "DPV and DPD over OCSP" Compliance Matrix

The following rating is my own rating.

SUMMARY

The overall rating is: 14/35.
The following points are met: 5, 6, 8, 9, 12, 16, 17, 18, 23, 26, 27, 28, 31 
and 33.

GENERAL COMMENTS

The DPV service is supported as an extension to OCSP. This means that the 
server MUST always support OCSP (i.e. provide the revocation status of the 
certificate) and provide a usual OCSP response with a major status relative 
to that OCSP request. However, a DPV server may well support certificate 
validation only using CRLs and no OCSP information at all. So it SHALL 
always provide an OCSP response, even if only CRLs are provided for the 
certificate to be validated.

If the major status from RFC 2560 is unknown, then it is quite artificial to 
support DPD through OCSP since the certification path could be returned, but 
not the revocation status of the certificate.

It should also be noticed that OCSP responses are always signed, whereas 
this is not a requirement for DPD (neither for DPV).

Renaming OCSP "ORS" for " On-line revocation Service" is not acceptable 
since this would confuse the PKIX community.

EXPLANATIONS

Point 1. "unsupportedPolicy" is not currently supported. The requirement is 
not met.

Point 2. ExtendedOCSP response indicates which policy has been used. 
However, a NULL OID is allowed which does not allow to know which policy has 
been used. In addition, if the policy includes parameters, these parameters 
are not indicated in the response. The requirement is not met.

Point 3. Trust points may not be enough. Since it is not possible to add 
additional parameters, this way to specify the parameters of the policy is 
not sufficient. revInfo from the request is not explained. Does it relate to 
useful certificates ? The requirement is not met.

Point 4. Not supported: the requirement is not met.

Point 5. The requirement is met.

Point 6. The requirement is met.

Point 7. revInfo is indeed part of the ExtendedOCSPRequest but not 
pathParams as indicated. DPVOptions is not part of the ExtendedOCSPRequest 
but of the ExtendedOCSPResponse. DPVOptions is not defined. The requirement 
is not met

Point 8. The requirement is met through the basic OCSP response.

Point 9. The requirement is met.

Point 10. The RFC2560 status does NOT govern production of errors for this 
extension. The requirement cannot be met by changing the meaning of the 
basic OCSP response. It could have been met if a separate status was 
provided in the ExtendedOCSPResponse. Since this is not the case, the 
requirement is not met.

Point 11. There is no detailed description of Reasons which is an octet 
string. The requirement is not met.

Point 12. The requirement is met.

Point 13. Flags allows to select what to be returned. However the way it is 
done is not appropriate for DPV since a single flag should be used to return 
all what is necessary to be compliant with the policy. The client being 
ignorant of the content of the policy cannot determine specifically what is 
to be returned. The requirement is not met.

Point 14. Since token is an OCTET STRING, it is not appropriate for a text 
field. The name of that field is not appropriate either. The requirement is 
not met.

Point 15. The requirement is met, but not using the explanations that are 
provided. There are met using paramHash, policy and reqCert from the basic 
OCSP. There are not met using DPVOptions which is left unspecified.

Point 16. The full OCSP response (for multiple certificate queries) is 
signed but not individual responses (for a single certificate). This forbids 
storing individual signed responses to prove later on that the individual 
response was correct. The functionality is supported, but not in an optimum way.

Point 17. The requirement is met.

Point 18. The requirement is met.

Point 19. The requirement is not met.

Point 20. The requirement is not met.

Point 21. The requirement is not met.

Point 22. The requirement is not met.

Point 23. The flags for Flags enable to request various information, but it 
is not specified that this is fully independent from validation, e.g. that 
the server shall not validate the certificate but only return the 
certification path. It seems that numPath present is the way to identify a 
DPD request from a DPV request. The requirement is met, but the text should 
be improved.

Point 24. Reporting errors relative to the extension through the major 
status of RFC 2560 not appropriate. The requirement is not met.

Point 25. More elaborated policies cannot be fully supported only using 
trust points. The requirement is not met.

Point 26. The requirement is met.

Point 27. The requirement is met.

Point 28. The requirement is met, not in an optimum way since all paths (up 
to the number that has been requested) are returned at once.

Point 29. The presence or absence of some fields does not allow to support 
all the options that are mentioned. Some additional flags or status are 
needed. The requirement is not met.

Point 30. RFC2560 does not enable responder signatures, but mandates them. 
The requirement is not met.

Point 31. The explanations that are provided about the use of lower layer 
security are not appropriate. However, since RFC 250 support optional 
signatures from the client, the requirement is met.

Point 32. The requirement is not met.

Point 33. No response provided. However, it may be supposed that this 
requirement is met.

Point 34. The requirement is not met.

Point 35. The requirement is not met.

Denis