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

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

[RFC 3379 requirements 25 through 34]

3379 Requirement #25. The DPD request MUST allow more elaborated path 
discovery policies to be referenced. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

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 #26. If the trust anchor is a self-signed certificate, 
that self-signed certificate MUST NOT be included.  In addition, if 
requested, the revocation information associated with each certificate in 
the path MUST also be returned. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD servers do not include the self-signed certificate in the returned path.

“The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  …  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.”
Section 4.9.5

“The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }”
Section 4.9.5

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

3379 Requirement #27. By default, the DPD server MUST return a single 
certification path for each end-entity certificate in the DPD request. (5. 
Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD clients specify the wantback id-swb-pkc-best-cert-path:

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

“The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  …  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.”
Section 4.9.5

If the DPD client checks revocation information, it will also spefiy the 
wantback id-swb-pkc-revocation-info:

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

“The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }”
Section 4.9.5

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

3379 Requirement #28. Therefore, the DPD client MUST have a means of 
obtaining more than one certification path for each end-entity certificate 
in the DPD request.  At the same time, the mechanism for obtaining 
additional certification paths MUST NOT impose protocol state on the DPD 
server. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

SCVP includes two mechanisms for obtaining additional paths:

(1) If the DPD client wishes to get all the paths the DPD server can find, 
the client asserts the wantback id-swb-pkc-all-cert-paths:

“- id-swb-pkc-all-cert-paths: A set of certification paths for the 
certificate.”
(Section 3.2.3)

“The octet string value for returning all paths, { id-swb 12 }, contains an 
ASN.1 type CertBundles, as defined below.  The syntax and semantics of the 
CertBundle type are described in section 3.2.8. Each CertBundle includes 
all the certificates in one path, starting the end certificate and ending 
with the certificate issued by the trust anchor.

       CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle”

(Section 4.9.5)

No state is imposed by this mechanism, since multiple paths are returned 
from a single request.

(2) The client may also request a single path at a time.  If the server 
detects multiple paths, it may include a serverContextInfo item in the 
response.  If the client does not like the certification path returned, it 
can make a new query and pass along this context information.  After 
obtaining each path, the client could submit the serverContextInfo from the 
previous request to obtain another path until the client either found a 
suitable path or the server indicated (by not returning a 
serverContextInfo) that no more paths were available.

The server may choose to implement serverContextInfo so that all necessary 
state information is embedded in the opaque blob, so state is not imposed 
by the protocol.  (A stateful implementation is also possible, of course.)

(Sections 3.2.6 and 4.11)

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

3379 Requirement #29. Path discovery MUST be performed according to the 
path discovery policy.  The DPD response MUST indicate one of the following 
status alternatives:
1.	one or more certification paths was found according to the path 
discovery policy, with all of the requested revocation information present.
2.	one or more certification paths was found according to the path 
discovery policy, with a subset of the requested revocation information 
present.
3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation information present.
4.	no certification path was found according to the path discovery policy.
5.	path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)

SCVP Draft 22:

This requirement is not fully satisfied.  The DPD response will not 
differentiate between states 2 and 3 as described in requirement 29.

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

State 1:  If one or more certification paths was found according to the 
path discovery policy, with all of the requested revocation information 
present, the replyStatus will be 0:

“0  Success: all checks were performed successfully.”

State 2:  If one or more certification paths was found according to the 
path discovery policy, but only a subset of the requested revocation 
information was available, the replyStatus will be 8:

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

State 3: If one or more certification paths was found according to the path 
discovery policy, but only a subset of the requested revocation information 
was available, the replyStatus will be 8:

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

State 4: If no certification path was found according to the path discovery 
policy, the replyStatus will be 5:

“5  Failure: no certification path could be constructed.”

State 5:  If path construction could not be performed due to an error, the 
replyStatus will be 1, 2, 3, or 4:

“  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
     3  Failure: historical data for the requested validity time is not
        available.
     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)

Possible resolution:  This requirement could be met by adding two 
additional reply check status codes for  { id-stc 1} -- but we do not see 
any value in this change!

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

3379 Requirement #30.   For the client to be confident that all of the 
elements from the response originate from the expected DPD server, an 
authenticated response MAY be required.  For example, the server might sign 
the response or data authentication might also be achieved using a 
lower-layer security protocol. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

“The protectResponse item indicates whether the client requires the server 
to protect the response.”  If asserted, the server digitally signs or MACs 
the response.

“SCVP servers MUST support returning protected responses”
(Section 3.2.5.3)

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

3379 Requirement #31. The DPD server MAY require client authentication, 
allowing the DPD request MUST to be authenticated. (5. Delegated Path 
Discovery Protocol)

SCVP Draft 22:

“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 #32. Using a separate request/response pair, the DPV or 
DPD client MUST be able to obtain references for the default policy or for 
all of the policies supported by the server. (6. DPV and DPD Policy Query)

SCVP Draft 22:

An SCVP client uses the Server Policy Request (i.e., the ValPolRequest 
item) “to request information about an SCVP server's policies and 
configuration information, including the list of validation policies 
supported by the SCVP server.”
(Section 5)
“In response to a ValPolRequest, the SCVP server provides a ValPolResponse.”

The ValPolResponse includes a comprehensive description of the default 
validation policy, as well as a list of all policies supported by the server.
(Section 6)

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

3379 Requirement #33. In order to succeed, one valid certification path 
(none of the certificates in the path are expired or revoked) MUST be found 
between an end-entity certificate and a trust anchor and all constraints 
that apply to the certification path MUST be verified. (7. Validation Policy)

SCVP Draft 22:

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

If one or more certification paths was found according to the validation 
policy, and all requested information  will be 0:

“0  Success: all checks were performed successfully.”

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

3379 Requirement #34. The validation policy MUST specify the source of 
revocation information:
1.	full CRLs (or full Authority Revocation Lists) have to be collected.
2.	OCSP responses, using [OCSP], have to be collected.
3.	delta CRLs and the relevant associated full CRLs (or full Authority 
Revocation Lists) are to be collected.
4.	any available revocation information has to be collected.
5.	no revocation information need be collected.
(Source for 34: 7.3. Revocation Requirements)

SCVP Draft 22:

The valPolResponse includes the revocationInfoTypes item.

RevocationInfoTypes ::= BIT STRING {
        fullCRLs                   (0),
        deltaCRLs                  (1),
        indirectCRLs               (2),
        oCSPResponses              (3) }

revocationInfoTypes allows the server to indicate the sources of revocation 
information that it is capable of processing.  For each bit in the 
RevocationInfoTypes bit string, the server MUST set the bit to one if it is 
capable of processing the corresponding revocation information type and to 
zero if it can not.

(Sections 6 and 6.11)