Subject: 3379 Compliance Matrix: SCVP-22 (2 of 3)

From: Tim Polk <[email-masked]>
Date: Thu, 26 Jan 2006 11:10:18 -0500

[RFC 3379 requirements 13 through 24]

3379 Requirement #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)

SCVP Draft 22:

Where requested, an SCVP server must return the certification path, status 
information (CRLs, OCSP responses and SCVP responses) and additional 
certificates required to validate the status information. This information 
is sufficient to verify that the validation has been performed correctly.

The SCVP client requests this information by asserting the wantbacks

“  - id-swb-pkc-best-cert-path: The certification path built for the 
certificate including the certificate that was validated;

     - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;

      - id-swb-relayed-responses: Any SCVP responses received by the server 
that were used to generate the response to this query.”
Section 3.2.3

Support for these wantbacks is optional for DPV servers and required for 
DPD servers:

“Conforming SCVP server implementations that support delegated path 
discovery (DPD) as defined in [RQMTS] MUST support the 
id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks.”
Section 3.2.3

If the requester asserts these codes and the SCVP server does not support 
them, the SCVP server must return the CVStatusCode “unsupportedWantBacks”
(Section 4.4)

     --------------------------

3379 Requirement #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)

SCVP Draft 22:

This requirement is poorly addressed in scvp-21

An SCVP request may include a requesterRef, which is a SEQUENCE of 
GeneralNames.

“If the SCVP client includes a requestorRef value in the request, then the 
SCVP server MUST return the same value if the server is generating a 
non-cached response.” Section 4.7

One legal value for a GeneralName is an IA5string, so we could argue that 
it is met, but this is a very poor fit.

Proposed Resolution:

Add an optional item, requesterText, to both the CVRequest and CVResponse 
sequences.  The responseText would be UTF8String, maximum size 256 
characters.  There would be no semantics; the server would be required to 
copy the value from the CVRequest into the CVResponse for all non-cached 
responses.

     --------------------------

3379 Requirement #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. 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)

SCVP Draft 22:

“By default, the server includes a hash of the request in non-cached 
responses to allow the client to identify the response.  If the client 
wants the server to include the full request in the non-cached response, 
fullRequestInResponse is set to TRUE. (section 3.2.5.1)

The DPV response and request are bound through inclusion of a hash of the 
request, or the request itself, for all non-cached responses.

If the requester chooses to accept cached responses, the client can still 
verify the binding by comparing the parameters from the request, such as 
the requested certificate and the validation policy, with the parameters in 
the cached response.

     --------------------------

3379 Requirement #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 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)

SCVP Draft 22:
“The protectResponse item indicates whether the client requires the server 
to protect the response. …

    SCVP clients that support delegated path validation (DPV) as defined in 
[RQMTS] require an authenticated response.  Unless a protected transport 
mechanism (such a TLS) is used, such clients MUST always set this value to 
TRUE or omit the responseFlags item entirely, which requires the server to 
return a protected response.

    SCVP servers MUST support returning protected responses…”

(Section 3.2.5.3)

If the client requests a protected response and signs the request, the 
server is required to sign the response.

(Section 4)

    --------------------------

3379 Requirement #17. The DPV server MAY require client authentication, 
therefore, the DPV request MUST be able to be authenticated. (4.1 Basic 
Protocol)

SCVP Draft 22:

“There are two forms of SCVP request: unprotected and protected.  A 
protected request is used to authenticate the client to the server or to 
provide anonymous client integrity over the request-response pair.  The 
protection is provided by a digital signature or message authentication 
code (MAC).  In the later case, the MAC key is derived using a key 
agreement algorithm, such as Diffie-Hellman.  If the client's public key is 
contained in a certificate, then it may be used to authenticate the 
client.  More commonly, the client's key agreement public key will be 
ephemeral, supporting anonymous client integrity.

A server MAY require all requests to be protected, and a server MAY discard 
all unprotected requests.  Alternatively, a server MAY choose to process 
unprotected requests.”

Section 3.

     --------------------------

3379 Requirement #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)

SCVP Draft 22:

“The optional requestorName item is used by the client to include an 
identifier in the request.  The client MAY include this information for the 
DPV server to copy into the response.

Conforming SCVP clients MAY support specification of this item in 
requests.  SCVP servers MUST be able to process requests that include this 
item.”

Section 3.5

“The optional requestorName item is used by the server to return one or 
more identities associated with the client in the response.

The SCVP server MAY choose to include any or all of the following:

      (1) the identity asserted by the client in the requestorName item of 
the request,
      (2) an authenticated identity for the client from a certificate or 
other credential used to authenticate the request, or
      (3) a client identifier from an out-of-band mechanism.

Alternatively, the SCVP server MAY omit this item.”

(Section 4.8)

      --------------------------

3379 Requirement #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)

SCVP Draft 22:

Servers that do not support redirection or relay are not required to 
process the requestorRef item or the responderName item.  The former is 
used for loop control, and is irrelevant for a server that does not itself 
relay requests.  The latter item identifies the intended signer, but 
servers that do not re-direct and sign under a single identity are not 
required to process this field.

As a general rule, redirection and relay are transparent to the 
client.  Clients are aware of redirection or relay only if they (1) wish to 
prompt redirection (through the responderName) or (2) request SCVP 
responses in the wantbacks.

(sections 3.2.3, 3.3, 3.6, 7)

      --------------------------

3379 Requirement #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)

SCVP Draft 22:

“When an SCVP server relays a request, the request MUST include the 
requestorRef item.  If the request to be relayed already contains a 
requestorRef item, then the server-generated request MUST contain a 
requestorRef item constructed from this value followed by a GeneralName 
that contains an identifier of the SCVP server.  If the request to be 
relayed does not contain a requestorRef item, then the server-generated 
request MUST contain a requestorRef item that includes a GeneralName that 
contains an identifier of the SCVP server.

When an SVCP server receives a request that contains a requestorRef item, 
the server MUST check the sequence of names in the requestorRef item for 
its own identifier.  If the server discovers its own identifier in the 
requestor item, it MUST respond with an error, setting the cvResponseStatus 
to 40.”

(Section 7)

     --------------------------

3379 Requirement #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)

SCVP Draft 22:
The client can manage redirection by including the responderName item.  The 
optional responderName item is used by the client to indicate the identity 
of the SCVP server that the client expects to sign the SCVP response if the 
response is digitally signed.  If the server that receives this request 
behaves as a proxy, it can use this field to determine where to direct the 
request.  The success of the redirection can be established by verifying 
the signature on the response.  The processing server returns its response 
to the proxy, which passes the SCVP response to the client.

(Sections 3.6 and 7)

     --------------------------

3379 Requirement #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)

SCVP Draft 22:

If an SCVP server returns a response that reflects the results of relay or 
redirection, this will be transparent to the client unless the client 
requested SCVP responses in the wantbacks.

- id-swb-relayed-responses: Any SCVP responses received by the server that 
were used to generate the response to this query.

In this case, any SCVP responses used by the server will be included in the 
response in replyWantBacks:

“The octet string value for relayed responses, { id-swb 13 }, contains an 
ASN.1 type SCVPResponses, as defined below.  If the SCVP server used 
information obtained from other SCVP servers when generating this response, 
then SCVPResponses MUST include each of the SCVP responses received from 
those servers.  If the SCVP server did not use information obtained from 
other SCVP servers when generating the response, then SCVPResponses MUST be 
an empty sequence.

(Sections 3.2.3, 4.9.5)

     --------------------------

3379 Requirement #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)
SCVP Draft 22:

SCVP does not permit the client to request status for just the EE 
certificate or just the CA certificates.  Clients that request status get 
status information for the entire path.

The SCVP client requests this information by asserting the wantback

“   - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;”
Section 3.2.3

Propose adding two new wantbacks, id-swb-ee-revocation-info and 
id-swb-CAs-revocation-info with the appropriate functionality.

     --------------------------

3379 Requirement #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)

SCVP Draft 22:

“If the server is unable to perform validations using the required 
validation policy or the request contains an unsupported option, then the 
server MUST return an error response.”

(Section 4)

     --------------------------