RFC 5055
Server-Based Certificate Validation Protocol (SCVP)
Pages: 88
Proposed Standard
Proposed Standard
Part 3 of 4 – Pages 36 to 57
3.3. requestorRef
The optional requestorRef item contains a list of names identifying SCVP servers, and it is intended for use in environments where SCVP relay is employed. Although requestorRef is encoded as a SEQUENCE, no order is implied. The requestorRef item is used to detect looping in some configurations. The value and use of requestorRef are described in Section 7. Conforming SCVP clients MAY support specification of the requestorRef value. Conforming SCVP server implementations MUST process the requestorRef value if present. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value in a non-cached response. The SCVP server MAY omit the requestorRef value from cached SCVP responses. The requestorRef item MUST be a sequence of GeneralName. No provisions are made to ensure uniqueness of the requestorRef GeneralName values.3.4. requestNonce
The optional requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference that the SCVP server SHOULD return a non-cached response. If the server returns a non-cached response, it MUST include the value of requestNonce from the request in the response as the respNonce item; however, the server MAY return a cached response which MUST NOT have a respNonce. SCVP clients that insist on creation of a fresh response (e.g., to protect against a replay attack or ensure information is up to date) MUST support requestNonce. Conforming SCVP server implementations MUST process the requestNonce value if present. If the client includes a requestNonce and also sets the cachedResponse flag to FALSE as described in Section 3.2.5.4, the client is indicating that the SCVP server MUST return either a non- cached response including the respNonce or an error response. The client SHOULD include a requestNonce item in every request to prevent
an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT set the cachedResponse flag to FALSE without also including a requestNonce. A server receiving such a request SHOULD return an invalidRequest error response. The requestNonce item, if present, MUST be an OCTET STRING that was generated exclusively for this request.3.5. requestorName
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.3.6. responderName
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. The responderName item SHOULD only be included if: 1. the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and 2. the responseFlags item is either absent or present with the protectResponse set to TRUE. Conforming SCVP clients MAY support specification of this item in requests. SCVP servers MUST be able to process requests that include this item. SCVP servers that maintain a single private key for signing SCVP responses or that are unable to return digitally signed responses MAY ignore the value in this item. SCVP servers that maintain more than one private key for signing SCVP responses SHOULD either (a) digitally sign the response using a private key that corresponds to a certificate that includes the name specified in responderName in either subject field or subjectAltName extension or (b) return a error indicating that the server does not possess a certificate that asserts the specified name.
3.7. requestExtensions
The OPTIONAL requestExtensions item contains extensions. If present, each extension in the sequence extends the request. This specification does not define any extensions; the facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The requestExtensions item, when present, MUST contain a sequence of Extension items, and each of the extensions MUST contain extnID, critical, and extnValue items. Each of these is described in the following sections.3.7.1. extnID
The extnID item is an identifier for the extension. It contains the object identifier that names the extension.3.7.2. critical
The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). By default, the extension is non-critical. An SCVP server MUST reject the query if it encounters a critical extension it does not recognize. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.3.7.3. extnValue
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.3.8. signatureAlg
The signatureAlg item contains an AlgorithmIdentifier indicating which algorithm the server should use to sign the response message. The signatureAlg item SHOULD only be included if: 1. the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and 2. the responseFlags item is either absent or present with the protectResponse set to TRUE. If included, the signatureAlg item SHOULD specify one of the signature algorithms specified in the signatureGeneration item of the server's validation policy response message.
SCVP servers MUST be able to process requests that include this item.
If the server is returning a digitally signed response to this
message, then:
1. If the signatureAlg item is present and specifies an algorithm
that is included in the signatureGeneration item of the server's
validation policy response message, the server MUST sign the
response using the signature algorithm specified in signatureAlg.
2. Otherwise, if the signatureAlg item is absent or is present but
specifies an algorithm that is not supported by the server, the
server MUST sign the response using the server's default signature
algorithm as specified in the signatureGeneration item of the
server's validation policy response message.
3.9. hashAlg
The hashAlg item contains an object identifier indicating which hash
algorithm the server should use to compute the hash value for the
requestHash item in the response. SCVP clients SHOULD NOT include
this item if fullRequestInResponse is set to TRUE. If included, the
hashAlg item SHOULD specify one of the hash algorithms specified in
the hashAlgorithms item of the server's validation policy response
message.
SCVP servers MUST be able to process requests that include this item.
If the server is returning a response to this message that includes a
requestHash, then:
1. If the hashAlg item is present and specifies an algorithm that is
included in the hashAlgorithms item of the server's validation
policy response message, the server MUST use the algorithm
specified in hashAlg to compute the requestHash.
2. Otherwise, if the hashAlg item is absent or is present but
specifies an algorithm that is not supported by the server, the
server MUST compute the requestHash using the server's default
hash algorithm as specified in the hashAlgorithms item of the
server's validation policy response message.
3.10. requestorText
SCVP clients MAY use the requestorText item to provide text for
inclusion in the corresponding response. For example, this field may
describe the nature or reason for the request.
Conforming SCVP client implementations MAY support inclusion of this item in requests. Conforming SCVP server implementations MUST accept requests that include this item. When generating non-cached responses, conforming SCVP server implementations MUST copy the contents of this item into the requestorText item in the corresponding response (see Section 4.13).3.11. SCVP Request Authentication
It is a matter of local policy what validation policy the server uses when authenticating requests. When authenticating protected SCVP requests, the SCVP servers SHOULD use the validation algorithm defined in Section 6 of [PKIX-1]. If the certificate used to validate a SignedData validation request includes the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set. If the certificate used to validate an AuthenticatedData validation request includes the key usage extension, it MUST have the key agreement bit set. If the certificate used on a validation request contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), the server SHALL verify that it contains the SCVP client OID, the anyExtendedKeyUsage OID, or another OID acceptable to the server. The SCVP client OID is defined as follows: id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } If a protected request fails to meet the validation policy of the server, it MUST be treated as an unauthenticated request.4. Validation Response
An SCVP server response to the client MUST be a single CVResponse item. When a CVResponse is encapsulated in a MIME body part, application/scvp-cv-response MUST be used. There are a number of forms of an SCVP response: 1. A success response to a request that has protectResponse set to FALSE. These responses SHOULD NOT be protected by the server.
2. The server MUST protect all other success responses. If the
server is unable to return a protected success response due to
local policy, then it MUST return an error response.
3. An error response to a request made over a protected transport
such as TLS. These responses SHOULD NOT be protected by the
server.
4. An error response to a request that has protectResponse set to
FALSE. These responses SHOULD NOT be protected by the server.
5. An error response to an authenticated request. The server SHOULD
protect these responses.
6. An error response to an AuthenticatedData request where MAC is
valid. The server MUST protect these responses.
7. All other error responses MUST NOT be protected by the server.
Successful responses are made when the server has fully complied with
the request. That is, the server was able to attempt to build a
certification path using the referenced or supplied validation
policy, and it was able to comply with all the requested parameters.
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.
For protected requests and responses, SCVP servers MUST support
SignedData and SHOULD support AuthenticatedData. It is a matter of
local policy which types are used. Where a protected response is
required, SCVP servers MUST use SignedData or AuthenticatedData, even
if the transaction is performed using a protected transport (e.g.,
TLS).
If the server is making a protected response to a protected request,
then the server MUST use the same protection mechanism (SignedData or
AuthenticatedData) as in the request.
An overview of the structure used for an unprotected response is
provided below. Many details are not shown, but the way that SCVP
makes use of CMS is clearly illustrated.
ContentInfo {
contentType id-ct-scvp-certValResponse,
-- (1.2.840.113549.1.9.16.1.11)
content CVResponse }
The protected response consists of a CVResponse encapsulated in either a SignedData or an AuthenticatedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of either SignedData or AuthenticatedData consists of an eContentType field with a value of id-ct-scvp-certValResponse and an eContent field that contains a DER-encoded CVResponse. The SCVP server MUST include its own certificate in the certificates field within SignedData. Other certificates MAY also be included. The SCVP server MAY also provide one or more CRLs in the crls field within SignedData. The signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field. The signedAttrs field within SignerInfo MUST include the content-type and message-digest attributes defined in [CMS], and it SHOULD include the signing-certificate attribute as defined in [ESS]. Within the signing-certificate attribute, the first certificate identified in the sequence of certificate identifiers MUST be the certificate of the SCVP server. The inclusion of other certificate identifiers in the signing-certificate attribute is OPTIONAL. The inclusion of policies in the signing-certificate is OPTIONAL. The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains information for the client that sent the request. The AuthenticatedData MUST NOT include the unauthAttrs field. The CVResponse item contains the server's response. The CVResponse MUST contain the cvResponseVersion, serverConfigurationID, producedAt, and responseStatus items. The CVResponse MAY also contain the respValidationPolicy, requestRef, requestorRef, requestorName, replyObjects, respNonce, serverContextInfo, and cvResponseExtensions items. The replyObjects item MUST contain exactly one CertReply item for each certificate requested. The requestorRef item MUST be included if the request included a requestorRef item and a non-cached response is provided. The respNonce item MUST be included if the request included a requestNonce item and a non-cached response is provided.
The CVResponse MUST have the following syntax:
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL,
requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL }
Conforming SCVP servers MAY be capable of constructing a CVResponse
that includes the serverContextInfo or cvResponseExtensions items.
Conforming SCVP servers MUST be capable of constructing a CVResponse
with any of the remaining optional items. Conforming SCVP clients
MUST be capable of processing a CVResponse with the following
optional items: respValidationPolicy, requestRef, requestorName,
replyObjects, and respNonce.
Conforming SCVP clients that are capable of including requestorRef in
a request MUST be capable of processing a CVResponse that includes
the requestorRef item. Conforming SCVP clients MUST be capable of
processing a CVResponse that includes the serverContextInfo or
cvResponseExtensions items. Conforming clients MUST be able to
determine if critical extensions are present in the
cvResponseExtensions item.
4.1. cvResponseVersion
The syntax and semantics of cvResponseVersion are the same as
cvRequestVersion as described in Section 3.1. The cvResponseVersion
MUST match the cvRequestVersion in the request. If the server cannot
generate a response with a matching version number, then the server
MUST return an error response that indicates the highest version
number that the server supports as the version number.
4.2. serverConfigurationID
The server configuration ID item represents the version of the SCVP
server configuration when it processed the request. See Section 6.4
for details.
4.3. producedAt
The producedAt item tells the date and time at which the SCVP server generated the response. The producedAt item MUST be expressed in UTC, and it MUST be interpreted as defined in Section 3.2.7. This value is independent of the validation time.4.4. responseStatus
The responseStatus item gives status information to the SCVP client about its request. The responseStatus item has a numeric status code and an optional string that is a sequence of characters from the ISO/IEC 10646-1 character set encoded with the UTF-8 transformation format defined in [UTF8]. The string MAY be used to transmit status information. The client MAY choose to display the string to a human user. However, because there is often no way to know the languages understood by a human user, the string may be of little or no assistance. The responseStatus item uses the ResponseStatus type, which has the following syntax: ResponseStatus ::= SEQUENCE { statusCode CVStatusCode DEFAULT okay, errorMessage UTF8String OPTIONAL } CVStatusCode ::= ENUMERATED { okay (0), skipUnrecognizedItems (1), tooBusy (10), invalidRequest (11), internalError (12), badStructure (20), unsupportedVersion (21), abortUnrecognizedItems (22), unrecognizedSigKey (23), badSignatureOrMAC (24), unableToDecode (25), notAuthorized (26), unsupportedChecks (27), unsupportedWantBacks (28), unsupportedSignatureOrMAC (29), invalidSignatureOrMAC (30), protectedResponseUnsupported (31), unrecognizedResponderName (32), relayingLoop (40), unrecognizedValPol (50),
unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }
The CVStatusCode values have the following meaning:
0 The request was fully processed.
1 The request included some unrecognized non-critical extensions;
however, processing was able to continue ignoring them.
10 Too busy; try again later.
11 The server was able to decode the request, but there was some
other problem with the request.
12 An internal server error occurred.
20 The structure of the request was wrong.
21 The version of request is not supported by this server.
22 The request included unrecognized items, and the server was not
able to continue processing.
23 The server could not validate the key used to protect the
request.
24 The signature or message authentication code did not match the
body of the request.
25 The encoding was not understood.
26 The request was not authorized.
27 The request included unsupported checks items, and the server was
not able to continue processing.
28 The request included unsupported wantBack items, and the server
was not able to continue processing.
29 The server does not support the signature or message
authentication code algorithm used by the client to protect the
request.
30 The server could not validate the client's signature or message
authentication code on the request.
31 The server could not generate a protected response as requested
by the client.
32 The server does not have a certificate matching the requested
responder name.
40 The request was previously relayed by the same server.
50 The request contained an unrecognized validation policy
reference.
51 The request contained an unrecognized validation algorithm OID.
52 The server does not support returning the full request in the
response.
53 The server does not support returning the full validation policy
by value in the response.
54 The server does not support the requested value for inhibit
policy mapping.
55 The server does not support the requested value for require
explicit policy.
56 The server does not support the requested value for inhibit
anyPolicy.
57 The server only validates requests using current time.
63 The query item in the request contains a critical extension whose
OID is not recognized.
64 The request contains a critical request extension whose OID is
not recognized.
Status codes 0-9 are reserved for codes that indicate the request was
processed by the server and therefore MUST be sent in a success
response. Status codes 10 and above indicate an error and MUST
therefore be sent in an error response.
4.5. respValidationPolicy
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. It MUST be present in success responses and
MUST NOT be present in error responses. The choice between returning
the policy by reference or by value is controlled by the
responseValidationPolByRef item in the request. The resultant
validation policy is the union of the following:
1. Values from the request.
2. For values that are not explicitly included in the request, values
from the validation policy specified by reference in the request.
The RespValidationPolicy syntax is:
RespValidationPolicy ::= ValidationPolicy
The validationPolicy item is defined in Section 3.2.4. When
responseValidationPolByRef is set to FALSE in the request, all items
in the validationPolicy item MUST be populated. When
responseValidationPolByRef is set to TRUE, OPTIONAL items in the
validationPolicy item only need to be populated for items for which
the value in the request differs from the value from the referenced
validation policy.
Conforming SCVP clients MUST be capable of processing the validation policy by reference. SCVP clients MAY be capable of processing the optional items in the validation policy. Conforming SCVP server implementations MUST be capable of asserting the policy by reference, and MUST be capable of including the optional items.4.6. requestRef
The requestRef item allows the SCVP client to identify the request that corresponds to this response from the server. It associates the response to a particular request using either a hash of the request or a copy of CVRequest from the request. The requestRef item does not provide authentication, but does allow the client to determine that the request was not maliciously modified. The requestRef item allows the client to associate a response with a request. The requestNonce provides an alternative mechanism for matching requests and responses. When the fullRequest alternative is used, the response provides a single data structure that is suitable for archive of the transaction. The requestRef item uses the RequestReference type, which has the following syntax: RequestReference ::= CHOICE { requestHash [0] HashValue, -- hash of CVRequest fullRequest [1] CVRequest } SCVP clients MUST support requestHash, and they MAY support fullRequest. SCVP servers MUST support using requestHash, and they SHOULD support using fullRequest.4.6.1. requestHash
The requestHash item is the hash of the CVRequest. The one-way hash function used to compute the hash of the CVRequest is as specified in Section 3.9. The requestHash item serves two purposes. First, it allows a client to determine that the request was not maliciously modified. Second, it allows the client to associate a response with a request when using connectionless protocols. The requestNonce provides an alternative mechanism for matching requests and responses.
The requestHash item uses the HashValue type, which has the following
syntax:
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It
is repeated here for convenience.
4.6.2. fullRequest
Like requestHash, the fullRequest alternative allows a client to
determine that the request was not maliciously modified. It also
provides a single data structure that is suitable for archive of the
transaction.
The fullRequest item uses the CVRequest type. The syntax and
semantics of the CVRequest type are described in Section 3.
4.7. requestorRef
The optional requestorRef item is used by the client to identify the
original requestor in cases where SCVP relay is used. The value is
only of local significance to the client. 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.
4.8. requestorName
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.
In the case of non-cached responses to authenticated requests, the SCVP server SHOULD return a requestor name. SCVP servers that support authenticated requests SHOULD support this item. SCVP clients MUST be able to process responses that include this item, although the item value might not impact the processing in any manner.4.9. replyObjects
The replyObjects item returns requested objects to the SCVP client, each of which tells the client about a single certificate from the request. The replyObjects item MUST be present in the response, unless the response is reporting an error. The CertReply item MUST contain cert, replyStatus, replyValTime, replyChecks, and replyWantBacks items, and the CertReply item MAY contain the validationErrors, nextUpdate, and certReplyExtensions items. A success response MUST contain one CertReply for each certificate specified in the queriedCerts item in the request. The order is important. The first CertReply in the sequence MUST correspond to the first certificate in the request, the second CertReply in the sequence MUST correspond to the second certificate in the request, and so on. The checks item in the request determines the content of the replyChecks item in the response. The wantBack item in the request determines the content of the replyWantBacks item in the response. The queryExtensions items in the request controls the absence or the presence and content of the certReplyExtensions item in the response. The replyObjects item uses the ReplyObjects type, which has the following syntax: ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply CertReply ::= SEQUENCE { cert CertReference, replyStatus ReplyStatus DEFAULT success, replyValTime GeneralizedTime, replyChecks ReplyChecks, replyWantBacks ReplyWantBacks, validationErrors [0] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, nextUpdate [1] GeneralizedTime OPTIONAL, certReplyExtensions [2] Extensions OPTIONAL }
4.9.1. cert
The cert item contains either the certificate or a reference to the certificate about which the client is requesting information. If the certificate was specified by reference in the request, the request included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and the server was able to obtain the referenced certificate, then this item MUST include the certificate. Otherwise, this item MUST include the same value as was used in the queriedCerts item in the request. CertReference has the following syntax: CertReference ::= CHOICE { pkc PKCReference, ac ACReference }4.9.2. replyStatus
The replyStatus item gives status information to the client about the request for the specific certificate. Note that the responseStatus item is different from the replyStatus item. The responseStatus item is the status of the whole request, while the replyStatus item is the status for the individual query item. The replyStatus item uses the ReplyStatus type, which has the following syntax: ReplyStatus ::= ENUMERATED { success (0), malformedPKC (1), malformedAC (2), unavailableValidationTime (3), referenceCertHashFail (4), certPathConstructFail (5), certPathNotValid (6), certPathNotValidNow (7), wantBackUnsatisfied (8) } The meanings of the various ReplyStatus values are: 0 Success: all checks were performed successfully. 1 Failure: the public key certificate was malformed. 2 Failure: the attribute certificate was malformed. 3 Failure: historical data for the requested validation 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. 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.
8 Failure: all checks were performed successfully; however, one or
more of the wantBacks could not be satisfied.
Codes 1 and 2 are used to tell the client that the request was
properly formed, but the certificate in question was not. This is
especially useful to clients that do not parse certificates.
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.
For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items
are not populated (i.e., they MUST be an empty sequence). For codes
5, 6, 7, and 8, replyChecks MUST include an entry corresponding to
each check in the request; the replyWantBacks item is not populated.
4.9.3. replyValTime
The replyValTime item tells the time at which the information in the
CertReply was correct. The replyValTime item represents the date and
time in UTC, using GeneralizedTime type. The encoding rules for
GeneralizedTime in Section 3.2.7 MUST be used.
Within the request, the optional validationTime item 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 respond as if the client provided the date and time at which the
server processes the request.
The information in the CertReply item MUST be formatted as if the
server created this portion of the response at the time indicated in
the validationTime item of the query. However, if the server does
not have appropriate historical information, the server MAY either
return an error or return information for a later time.
4.9.4. replyChecks
The replyChecks item contains the responses to the checks item in the
query. The replyChecks item includes the object identifier (OID)
from the query and an integer. The value of the integer indicates
whether the requested check was successful. The OIDs in the checks
item of the query are used to identify the corresponding replyChecks
values. Each OID specified in the checks item in the request MUST be
matched by an OID in the replyChecks item of the response. In the
case of an error response, the server MAY include additional checks
in the response to further explain the error. Clients MUST ignore
any unrecognized ReplyCheck included in the response.
The replyChecks item uses the ReplyChecks type, which has the
following syntax:
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
The status value for public key certification path building to a
trusted root, { id-stc 1 }, can be one of the following:
0: Built a path
1: Could not build a path
The status value for public key certification path building to a
trusted root along with simple validation processing, { id-stc 2 },
can be one of the following:
0: Valid
1: Not valid
The status value for public key certification path building to a
trusted root along with complete status checking, { id-stc 3 }, can
be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation information
Revocation off-line means that the server or distribution point for
the revocation information was connected to successfully without a
network error but either no data was returned or if data was returned
it was stale. Revocation unavailable means that a network error was
returned when an attempt was made to reach the server or distribution
point. No known source for revocation information means that the
server was able to build a valid certification path but was unable to
locate a source for revocation information for one or more
certificates in the path.
The status value for AC issuer certification path building to a
trusted root, { id-stc 4 }, can be one of the following:
0: Built a path
1: Could not build a path
The status value for AC issuer certification path building to a
trusted root along with simple validation processing, { id-stc 5 },
can be one of the following:
0: Valid
1: Not valid
The status value for AC issuer certification path building to a
trusted root along with complete status checking, { id-stc 6 }, can
be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation information
The status value for revocation status checking of an AC as well as
AC issuer certification path building to a trusted root along with
complete status checking, { id-stc 7 }, can be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation information
4.9.5. replyWantBacks
The replyWantBacks item contains the responses to the wantBack item
in the request. The replyWantBacks item includes the object
identifier (OID) from the wantBack item in the request and an OCTET
STRING. Within the OCTET STRING is the requested value. The OIDs in
the wantBack item in the request are used to identify the
corresponding reply value. The OIDs in the replyWantBacks item MUST
match the OIDs in the wantBack item in the request. For a non-error
response, replyWantBacks MUST include exactly one ReplyWantBack for
each wantBack specified in the request (excluding id-swb-pkc-cert and
id-swb-ac-cert, where the requested information is included in the
cert item).
The replyWantBacks item uses the ReplyWantBacks type, which has the
following syntax:
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
The OCTET STRING value for the certification path used to verify the
certificate in the request, { id-swb 1 }, contains the CertBundle
type. The syntax and semantics of the CertBundle type are described
in Section 3.2.8. This CertBundle includes all the certificates in
the path, starting with the end certificate and ending with the
certificate issued by the trust anchor.
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 wantBack. The CertBundle MUST include all
such certificates, but there are no ordering requirements.
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
The OCTET STRING value for the public key information, { id-swb 4 },
contains the SubjectPublicKeyInfo type. The syntax and semantics of
the SubjectPublicKeyInfo type are described in [PKIX-1].
The OCTET STRING value for the AC issuer certification path used to
verify the certificate in the request, { id-swb 5 }, contains the
CertBundle type. The syntax and semantics of the CertBundle type are
described in Section 3.2.8. This CertBundle includes all the
certificates in the path, beginning with the AC issuer certificate
and ending with the certificate issued by the trust anchor.
The OCTET STRING value for the proof of revocation status of the AC
issuer certification path, { id-swb 6 }, 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-aa-cert-path
wantBack. The CertBundle MUST include all such certificates, but
there are no ordering requirements.
The OCTET STRING value for the proof of revocation status of the
attribute certificate, { id-swb 7 }, 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-aa-cert-path
wantBack. The CertBundle MUST include all such certificates, but
there are no ordering requirements.
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
with the end certificate and ending with the certificate issued by
the trust anchor.
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
The OCTET STRING value for relayed responses, { id-swb 9 }, 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.
SCVPResponses ::= SEQUENCE OF ContentInfo
The OCTET STRING value for the proof of revocation status of the
path's target certificate, { id-swb-13 }, 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 wantBack. The
CertBundle MUST include all such certificates, but there are no
ordering requirements.
The OCTET STRING value for the proof of revocation status of the
intermediate certificates in the path, { id-swb 14 }, 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 wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.4.9.6. validationErrors
The validationErrors item MUST only be present in failure responses. If present, it MUST contain one or more OIDs representing the reason the validation failed (validation errors for the basic validation algorithm and name validation algorithm are defined in Sections 3.2.4.2.2 and 3.2.4.2.4). 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.4.9.7. nextUpdate
The nextUpdate item tells the time at which the server expects a refresh of information regarding the validity of the certificate to become available. The nextUpdate item is especially interesting if the certificate revocation status information is not available or the certificate is suspended. The nextUpdate item represents the date and time in UTC, using the GeneralizedTime type. The encoding rules for GeneralizedTime in Section 3.2.7 MUST be used.4.9.8. certReplyExtensions
The certReplyExtensions item contains the responses to the queryExtensions item in the request. The certReplyExtensions item uses the Extensions type defined in [PKIX-1]. The object identifiers (OIDs) in the queryExtensions item in the request are used to identify the corresponding reply values. The certReplyExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item. The extnID item is an identifier for the extension. It contains the OID that names the extension, and it MUST match one of the OIDs in the queryExtensions item in the request. The critical item is a BOOLEAN, and it MUST be set to FALSE.
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.
(page 57 continued on part 4)