Subject: Rating of the SCVP Compliance Matrix

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

Rating of the SCVP Compliance Matrix

The following rating is my own rating.

SUMMARY

The following points are met: 1, 4, 5, 6, 8, 9, 10, 11, 12, 17, 23, 26, 27, 
28, 29, 30, 31, 32, 33, 34.
The following points are met, but not in an optimum way: 13, 16.
The following points are not correctly met or partly met: 2, 7, 15, 24, 35.
The following points are not met: 3, 14, 18, 19, 20, 21, 22, 25.

The overall rating is: 22/35 or 27/35 depending on the way to count “not 
correctly met or partly met”.

GENERAL COMMENT

There is an over-use (or abuse of use) of OIDs everywhere, in this document. 
In many places tags or enumerated values could be used instead. This would 
make the syntax simpler, and easier to debug.

EXPLANATIONS

Point 1. The requirement is met.

Point 2. The use of the server default policy does not allow to know which 
policy has been used. The requirement is only partly met.

Point 3. The use of a mixture of policy and other parameters (valPolicy and 
trustAnchors) does not allow to support, as indicated in the matrix, an OID 
followed by additional parameters. The requirement is not met.

Point 4. The requirement is met.

Point 5. The requirement is met.

Point 6. The requirement is met.

Point 7. The use of trust anchors is not appropriate. They are not 
independent of the policy but under the policy. The requirement is not 
correctly met.

Point 8. The requirement is met.

Point 9. The fact that the server always return the certificate is not easy 
for light clients that will have to verify that it matches the ESSCertID if 
ESSCertID is being used. Nevertheless, the requirement is met.

Point 10. The requirement is met.

Point 11. The requirement is met.

Point 12. The requirement is met.

Point 13. The text states:  "The octet string value for the proof of 
revocation status,  { id-swb 2 }, contains the RevocationInfo type." There 
is a small error here: RevocationInfo has to be replaced by RevocationInfos. 
I believe that this is the intended left error to make sure that the 
specification has really been read. :-)

The answer is signed but this is far from optimum since the signed answer is 
quite big when it is for multiple certificates and the certification path 
(including the revocation information) is also provided. In many cases, a 
relying party would like to store the signed answer for just one certificate 
and thus be able to provide the proof that the checking was done without the 
need to communicate the answers for other certificates. In case of a 
dispute, the relying party would then need to provide the certification path 
(including the revocation information) but this does not mean that two 
signed answers should be provided, one with the certification path 
(including the revocation information) and one without. There exists a 
technique allowing to get a single proof and to also protect the 
certification path (including the revocation information). This technique is 
being used in CVP: the hash of the certification path (including the 
revocation information) is included in an individual signed answer.

The requirement is met, but not in an optimum way.

Point 14. The requirement is not met since the requestor item serves for 
three different purposes.

Point 15. RequestReference is a CHOICE between requestHash and fullRequest. 
However there is no indication to know when each option shall be used. If 
requestHash is used, then the information is not sufficient. If fullRequest 
is used then the response is rather big and includes useless information. 
Ideally a combination of requestHash and of CertReference and the policy 
(with optional parameters when needed) would do the job. The requirement is 
partly met.

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 requestor is unrelated to the authentication of the client. 
The requirement is not met.

Point 19. The requestor item is used to detect relay loops, but it is also 
used for another purpose. This currently forbids that the identifier 
includes any zero octets. The requirement is not met.

Point 20. The use of uses the requestor item to detect relay loops is not 
appropriate, since requestor serves for two and even three different 
purposes. The requirement is not met.

Point 21. SCVP does not support referrals. The requirement is not met.

Point 22. The requirement is not met since requestor serves for two and even 
three different purposes.

Point 23. The requirement is met.

Point 24. The use of the server default policy does not allow to know which 
policy has been used. The requirement is only partly met.

Point 25. The use of a mixture of policy and other parameters (valPolicy and 
trustAnchors) does not allow to support, as indicated in the matrix, an OID 
followed by additional parameters. The requirement is not met.

Point 26. The requirement is met.

Point 27. The requirement is met.

Point 28. The requirement is met.

Point 29. The requirement is met.

Point 30. The requirement is met.

Point 31. The requirement is met.

Point 32. The requirement is met.

Point 33. The requirement is met.

Point 34. The requirement is met.

Point 35. On one side SCVP defines the syntax of a validation policy as an 
OID followed by optional parameters, but on other side SCVPO defines a 
default policy which does not conform to this. The requirement is partly 
met, or will be met if the default policy concept is withdrawn.

Denis