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

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

[RFC 3379 requirements 1 through 12]

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

SCVP Draft 22:

DPV responses include the responseStatus item.  If the client asserts the 
OID for an unsupported validation policy, the SCVP server returns an error 
response and specifies the statusCode unrecognizedValPol.

SCVP draft -21 specifies that unrecognizedValPol has the meaning “The 
request contained an unrecognized validation policy reference.” (section 4.4)

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

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

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server’s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

All DPV success responses include respValidationPolicy item (section 4.5), 
which indicate the validation policy that was used:

“The respValidationPolicy item contains either a reference to the full 
validation policy or the full policy by value used by the server to 
validate the request.”

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

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

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server’s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

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

3379 Requirement #4. The DPV server MUST obtain revocation status 
information for the validation time in the client request. (4.1. Basic 
Protocol)

SCVP Draft 22:

An SCVP client specifies the validation time  by including the optional 
validationTime item (section 3.2.7)

“The optional validationTime item, if present, tells the date and time 
relative to which the SCVP client wants the server to perform the 
checks.  If the validationTime is not present, the server MUST perform the 
validation using the date and time at which the server processes the request.”

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

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

SCVP Draft 22:

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the revocation status information for the requested validation time is 
unavailable, the replyStatus will be 0 or 7:

“3  Failure: historical data for the requested validity time is notavailable.
    ….

7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
    …

    Code 7 is used to tell the client that a valid certification path was 
found with the exception that a certificate in the path is on hold, current 
revocation information is unavailable, or the validation time precedes the 
notBefore time in one or more certificates in the path.”

(Section 4.9.2)

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

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

SCVP Draft 22:

The requestor specifies the list of certificates to be  validated in the 
sequence CertReferences.  Certificate references are performed by inclusion 
of the certificate itself or are specified using the CertID structure, 
which is based on the ESSCertID. The CertID structure includes the hash of 
the certificate and the issuer and serial number.  (section 3.2.1)

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

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

SCVP Draft 22:

The DPV client can include potentially useful certificates in the request 
in the optional intermediateCerts item (section 3.2.8):

“The optional intermediateCerts item may help the SCVP server create valid 
certification paths.  The intermediateCerts item, when present, provides 
certificates that the server MAY use when forming a certification path.”

The DPV client can include potentially useful revocation information in the 
request in the optional revInfos item (section 3.2.9):

“The optional revInfos item specifies revocation information such as CRLs, 
delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP server MAY use 
when validating certification paths.  The purpose of the revInfos item is 
to provide revocation information to which the server might not otherwise 
have access, such as an OCSP response that the client received along with 
the certificate.”

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

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

SCVP Draft 22:

The DPV client must either explicitly provide the certificate to be 
validated to the DPV server or reference the certificate by its hash value 
in the queriedCerts item.

(Section 3.2.1)

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the certificate is not included in the request (i.e., the certificate is 
referenced by hash value), and the server is unable to obtain the 
certificate, the replyStatus will be 4:

“4  Failure: the server could not locate the reference certificate or the 
referenced certificate did not match the hash value provided.”

(Section 4.9.2)

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

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

SCVP Draft 22:

The DPV server includes a certReply in the replyObjects in the response for 
each certificate that was validated.  The certReply is a sequence that 
includes the mandatory cert item (section 4.9.1)

“The cert item contains either the certificate or a reference to the 
certificate about which the client is requesting information.”

The CertID structure is used when the server specifies the certificate by 
reference.

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

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

SCVP Draft 22:

The replyStatus item gives status information to the client about the 
request for the specific certificate.

If the certificate is valid according to the validation policy, the 
replyStatus will be 0 or 8:

“0  Success: all checks were performed successfully.”

“8  Failure: all checks were performed successfully, however one or more of 
the wantBacks could not be satisfied.”

If the certificate is not valid according to the validation policy, the 
replyStatus will be 6 or 7:

“6  Failure: the constructed certification path is not valid with respect 
to the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.”

If the validity of the certificate is unknown according to the validation 
policy, the replyStatus will be 3 or 5:

“3  Failure: historical data for the requested validity time is not available.
    ….
5       Failure: no certification path could be constructed.”

If the validity could not be determined due to an error, the replyStatus 
will be 1, 2, or 4:

“  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
   ….
     4  Failure: the server could not locate the reference certificate or 
the referenced certificate did not match the hash value provided.

(Section 4.9.2)

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

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

SCVP Draft 22:

These reasons correspond to replyStatus codes 5, 6, and 7 respectively.

5  Failure: no certification path could be constructed.
6  Failure: the constructed certification path is not valid with respect to 
the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
(Section 4.9.2)

Additional information may be provided by the validation Errors field.

“The validationErrors item SHOULD only be included when the replyStatus is 
3, 5, 6, 7, or 8.  SCVP servers are not required to specify all of the 
reasons that validation failed. SCVP clients MUST NOT assume that the OIDs 
included in validationErrors represent all of the validation errors for the 
certification path.”
Section 4.9.6

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

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

SCVP Draft 22:

SCVP includes a nonce mechanism to prevent replay attacks:

The requester may include a nonce in the request item requestNonce; the 
server returns this nonce in the response item respNonce. (section 3.4)

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