Subject: Rating of the DVCS Compliance Matrix

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

Rating of the DVCS Compliance Matrix

The following rating is my own rating.

SUMMARY

The requirements that are met correspond to the following points:
6, 9, 15, 16, 17 and 18. The overall rating is thus: 6/35.

EXPLANATIONS

Since DVCS does not distinguish between DPV and DPD, DPD is not supported as 
requested by RFC 3379. So the conformance points 23 to 35 should be rated 0.

For the other conformance points:

Point 1. If the policy field is missing, "any policy" is not acceptable. The 
requirement is not met.

Point 2. Since policy is optional in the response, the "MUST" requirement is 
not met.

Point 3. The description of TargEtcChain is insufficient to under stand how 
the structure SHALL be used to support the feature.

Point 4. No handling is indicated.

Point 5. No specific error returned.

Point 6. Rather complicated, but the functionality is there.

Point 7. There is no concept of useful certificates, CRLs or OCSP responses. 
On the contrary in page 20 what is provided MUST be used. The point is not met.

Point 8. The text does not say it.

Point 9. The requirement is met.

Point 10. The requirement is not met, since the PKIstatus does not allow to 
report all the cases.

Point 11. The requirement is not met, since the PKIstatus does not allow to 
report all the cases.

Point 12. The chaining of nonces as described does not work. Nonce is an 
integer and a concatenation of nonces as integers does not work. The 
requirement is not met.

Point 13. There is no way to make to request this feature. The requirement 
is  not met.

Point 14. It is unclear how the requestPolicy in DVCSRequestInformation and 
policy in DVCSCertInfo work together. They seem to conflict.

Point 15. The requirement is supported, but since the full request is 
copied, this is not optimum.

Point 16. The full response (for multiple certificates) 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. Relaying is supported through embedded signed responses which 
overload the client. So the requirement is not met.

Point 20. There are no explanations about how to detect loops. The 
requirement is not met.

Point 21. The requirement is not met.

Point 22. There is no support of re-direction. The requirement is not met.

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 27 Jan 2003 17:03:09 +0100 (MET)

Without having made an update like an RFC 3029bis the score isn't
that bad and several points just need a textual clarifications.

An interesting comparision would be to compare OCSP and
SCVP drafts of about one year ago.  :-) 

Some examples for RFC 3029bis:

1   If the DPV server does not support the client requested validation
   policy, then the DPV server MUST return an error.

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

   - The 'requestPolicy' field SHOULD indicate the policy under which
     the validation is requested.  This field MUST be checked by the
     DVCS to verify agreement with its own policy.  The absence of this
     field indicates that any policy is acceptable.

   - The 'DVCSCertInfo.policy' field indicates the policy under which
     the DVCS operates.

The missing point in 3029 is that when the field is not accepted, 
the server returns an error    unacceptedPolicy    (15),
which is defined as in 3161 and CMPbis but was not available
at the time when the RFC was written. 

     -- the requested TSA policy is not supported by the TSA
 
> Point 2. Since policy is optional in the response, the "MUST" requirement is 

the policy is optional in the response, since there is no requirement
to always return it. 

The requirement in 3379 allows that the field is optional both in the
request and the response. 

In 3029 there is a syntactical possibility that no policy is exchanged
at all. I'm happy to remedy this by adding a statement like
'The server SHOULD set the 'DVCSCertInfo.policy' field if the client
has not specified it in the request.' A SHOULD because there may be
very special cases where a client an a server agree on *THE*
policy, they simply don't need anything at all. 

> overload the client. So the requirement is not met.

The additional information provided is identical to the
information of the general structure. Thus, there is not an
additional burden of code, a client can also ignore this, and
just react to the status; a policy may still decide not to
return the information. 

> Point 20. There are no explanations about how to detect loops. The 
Well, indeed, it seems that the texts needs more clarification. The
examples in the description of 'requester' is not obvious. Since

I was at the origin of that requirement, here a text:  

- Each relay adds its own id and checks incoming requests for 
  its own name AND whether an outgoing request goes to one already in the list. 

- This general idea MAY have exceptions, e.g., when a relay does not
  want to indicate the identity of its client to another server
  it may remove the incoming value before relaying.