RFC 5055 - Server-Based Certificate Validation Protocol (SCVP)
(Formats: TXT)
Network Working Group T. Freeman
Request for Comments: 5055 Microsoft Corp
Category: Standards Track R. Housley
Vigil Security
A. Malpani
Malpani Consulting Services
D. Cooper
W. Polk
NIST
December 2007
|
Server-Based Certificate Validation Protocol (SCVP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Server-Based Certificate Validation Protocol (SCVP) allows a
client to delegate certification path construction and certification
path validation to a server. The path construction or validation
(e.g., making sure that none of the certificates in the path are
revoked) is performed according to a validation policy, which
contains one or more trust anchors. It allows simplification of
client implementations and use of a set of predefined validation
policies.
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. SCVP Overview ..............................................5
1.3. SCVP Requirements ..........................................5
1.4. Validation Policies ........................................6
1.5. Validation Algorithm .......................................7
1.6. Validation Requirements ....................................8
2. Protocol Overview ...............................................9
3. Validation Request ..............................................9
3.1. cvRequestVersion ..........................................12
3.2. query .....................................................12
3.2.1. queriedCerts .......................................13
3.2.2. checks .............................................15
Freeman, et al. Standards Track [Page 1]
RFC 5055 SCVP December 2007
3.2.3. wantBack ...........................................16
3.2.4. validationPolicy ...................................19
3.2.4.1. validationPolRef ..........................20
3.2.4.1.1. Default Validation Policy ......21
3.2.4.2. validationAlg .............................22
3.2.4.2.1. Basic Validation Algorithm .....22
3.2.4.2.2. Basic Validation
Algorithm Errors ...............23
3.2.4.2.3. Name Validation Algorithm ......24
3.2.4.2.4. Name Validation
Algorithm Errors ...............25
3.2.4.3. userPolicySet .............................26
3.2.4.4. inhibitPolicyMapping ......................26
3.2.4.5. requireExplicitPolicy .....................27
3.2.4.6. inhibitAnyPolicy ..........................27
3.2.4.7. trustAnchors ..............................27
3.2.4.8. keyUsages .................................28
3.2.4.9. extendedKeyUsages .........................28
3.2.4.10. specifiedKeyUsages .......................29
3.2.5. responseFlags ......................................30
3.2.5.1. fullRequestInResponse .....................30
3.2.5.2. responseValidationPolByRef ................30
3.2.5.3. protectResponse ...........................31
3.2.5.4. cachedResponse ............................31
3.2.6. serverContextInfo ..................................32
3.2.7. validationTime .....................................32
3.2.8. intermediateCerts ..................................33
3.2.9. revInfos ...........................................34
3.2.10. producedAt ........................................35
3.2.11. queryExtensions ...................................35
3.2.11.1. extnID ...................................35
3.2.11.2. critical .................................35
3.2.11.3. extnValue ................................36
3.3. requestorRef ..............................................36
3.4. requestNonce ..............................................36
3.5. requestorName .............................................37
3.6. responderName .............................................37
3.7. requestExtensions .........................................38
3.7.1. extnID .............................................38
3.7.2. critical ...........................................38
3.7.3. extnValue ..........................................38
3.8. signatureAlg ..............................................38
3.9. hashAlg ...................................................39
3.10. requestorText ............................................39
3.11. SCVP Request Authentication ..............................40
4. Validation Response.............................................40
4.1. cvResponseVersion...........................................43
4.2. serverConfigurationID.......................................43
Freeman, et al. Standards Track [Page 2]
RFC 5055 SCVP December 2007
4.3. producedAt..................................................44
4.4. responseStatus..............................................44
4.5. respValidationPolicy........................................46
4.6. requestRef..................................................47
4.6.1. requestHash ........................................47
4.6.2. fullRequest ........................................48
4.7. requestorRef................................................48
4.8. requestorName...............................................48
4.9. replyObjects................................................49
4.9.1. cert................................................50
4.9.2. replyStatus.........................................50
4.9.3. replyValTime .......................................51
4.9.4. replyChecks ........................................51
4.9.5. replyWantBacks .....................................53
4.9.6. validationErrors ...................................56
4.9.7. nextUpdate .........................................56
4.9.8. certReplyExtensions ................................56
4.10. respNonce..................................................57
4.11. serverContextInfo..........................................57
4.12. cvResponseExtensions ......................................58
4.13. requestorText .............................................58
4.14. SCVP Response Validation ..................................59
4.14.1. Simple Key Validation .............................59
4.14.2. SCVP Server Certificate Validation ................59
5. Server Policy Request...........................................60
5.1. vpRequestVersion...........................................60
5.2. requestNonce...............................................60
6. Validation Policy Response......................................61
6.1. vpResponseVersion..........................................62
6.2. maxCVRequestVersion........................................62
6.3. maxVPRequestVersion........................................62
6.4. serverConfigurationID......................................62
6.5. thisUpdate.................................................63
6.6. nextUpdate and requestNonce................................63
6.7. supportedChecks............................................63
6.8. supportedWantBacks.........................................64
6.9. validationPolicies.........................................64
6.10. validationAlgs............................................64
6.11. authPolicies..............................................64
6.12. responseTypes.............................................64
6.13. revocationInfoTypes.......................................64
6.14. defaultPolicyValues.......................................65
6.15. signatureGeneration ......................................65
6.16. signatureVerification ....................................65
6.17. hashAlgorithms ...........................................66
6.18. serverPublicKeys .........................................66
6.19. clockSkew ................................................66
7. SCVP Server Relay...............................................67
Freeman, et al. Standards Track [Page 3]
RFC 5055 SCVP December 2007
8. SCVP ASN.1 Module...............................................68
9. Security Considerations.........................................76
10.IANA Considerations.............................................78
11. References.....................................................78
11.1. Normative References.....................................78
11.2. Informative References...................................79
12. Acknowledgments................................................80
Appendix A. MIME Media Type Registrations..........................81
A.1. application/scvp-cv-request..............................81
A.2. application/scvp-cv-response.............................82
A.3. application/scvp-vp-request..............................83
A.4. application/scvp-vp-response.............................84
Appendix B. SCVP over HTTP.........................................85
B.1. SCVP Request.............................................85
B.2. SCVP Response............................................85
B.3. SCVP Policy Request......................................86
B.4. SCVP Policy Response.....................................86
1. Introduction
Certificate validation is complex. If certificate handling is to be
widely deployed in a variety of applications and environments, the
amount of processing an application needs to perform before it can
accept a certificate needs to be reduced. There are a variety of
applications that can make use of public key certificates, but these
applications are burdened with the overhead of constructing and
validating the certification paths. SCVP reduces this overhead for
two classes of certificate-using applications.
The first class of applications wants just two things: confirmation
that the public key belongs to the identity named in the certificate
and confirmation that the public key can be used for the intended
purpose. Such clients can completely delegate certification path
construction and validation to the SCVP server. This is often
referred to as delegated path validation (DPV).
The second class of applications can perform certification path
validation, but they lack a reliable or efficient method of
constructing a valid certification path. Such clients delegate
certification path construction to the SCVP server, but not
validation of the returned certification path. This is often
referred to as delegated path discovery (DPD).
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [STDWORDS].
Freeman, et al. Standards Track [Page 4]
RFC 5055 SCVP December 2007
1.2. SCVP Overview
The primary goals of SCVP are to make it easier to deploy Public Key
Infrastructure (PKI)-enabled applications by delegating path
discovery and/or validation processing to a server, and to allow
central administration of validation policies within an organization.
SCVP can be used by clients that do much of the certificate
processing themselves but simply want an untrusted server to collect
information for them. However, when the client has complete trust in
the SCVP server, SCVP can be used to delegate the work of
certification path construction and validation, and SCVP can be used
to ensure that policies are consistently enforced throughout an
organization.
Untrusted SCVP servers can provide clients the certification paths.
They can also provide clients the revocation information, such as
Certificate Revocation Lists (CRLs) and Online Certificate Status
Protocol (OCSP) responses, that the clients need to validate the
certification paths constructed by the SCVP server. These services
can be valuable to clients that do not implement the protocols needed
to find and download intermediate certificates, CRLs, and OCSP
responses.
Trusted SCVP servers can perform certification path construction and
validation for the client. For a client that uses these services,
the client inherently trusts the SCVP server as much as it would its
own certification path validation software (if it contained such
software). There are two main reasons that a client may want to
trust such an SCVP server:
1. The client does not want to incur the overhead of including
certification path validation software and running it for each
certificate it receives.
2. The client is in an organization or community that wants to
centralize management of validation policies. These policies
might dictate that particular trust anchors are to be used and the
types of policy checking that are to be performed during
certification path validation.
1.3. SCVP Requirements
SCVP meets the mandatory requirements documented in [RQMTS] for DPV
and DPD.
Freeman, et al. Standards Track [Page 5]
RFC 5055 SCVP December 2007
Note that RFC 3379 states the following requirement:
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.
DPD responses constructed by SCVP servers do not differentiate
between states 2) and 3). This property was discussed on the PKIX
working group list and determined to be conformant with the intent of
[RQMTS].
1.4. Validation Policies
A validation policy (as defined in RFC 3379 [RQMTS]) specifies the
rules and parameters to be used by the SCVP server when validating a
certificate. In SCVP, the validation policy to be used by the server
either can be fully referenced in the request by the client (and thus
no additional parameters are necessary) or can be referenced in the
request by the client with additional parameters.
Policy definitions can be quite long and complex, and some policies
may allow for the setting of a few parameters. The request can
therefore be very simple if an object identifier (OID) is used to
specify both the algorithm to be used and all the associated
parameters of the validation policy. The request can be more complex
if the validation policy fixes many of the parameters but allows the
client to specify some of them. When the validation policy defines
every parameter necessary, an SCVP request needs only to contain the
certificate to be validated, the referenced validation policy, and
any run-time parameters for the request.
Freeman, et al. Standards Track [Page 6]
RFC 5055 SCVP December 2007
A server publishes the references of the validation policies it
supports. When these policies have parameters that may be
overridden, the server communicates the default values for these
parameters as well. The client can simplify the request by omitting
a parameter from a request if the default value published by the
server for a given validation policy reference is acceptable.
However, if there is a desire to demonstrate to someone else that a
specific validation policy with all its parameters has been used, the
client will need to ask the server for the inclusion of the full
validation policy with all the parameters in the response.
The inputs to the basic certification path processing algorithm used
by SCVP are defined by [PKIX-1] in Section 6.1.1 and comprise:
Certificate to be validated (by value or by reference);
Validation time;
The initial policy set;
Initial inhibit policy mapping setting;
Initial inhibit anyPolicy setting; and
Initial require explicit policy setting.
The basic certification path processing algorithm also supports
specification of one or more trust anchors (by value or reference) as
an input. Where the client demands a certification path originating
with a specific Certification Authority (CA), a single trust anchor
is specified. Where the client is willing to accept paths beginning
with any of several CAs, a set of trust anchors is specified.
The basic certification path processing algorithm also supports the
following parameters, which are defined in [PKIX-1], Section 4:
The usage of the key contained in the certificate (e.g., key
encipherment, key agreement, signature); and
Other application-specific purposes for which the certified public
key may be used.
1.5. Validation Algorithm
The validation algorithm is determined by agreement between the
client and the server and is represented as an OID. The algorithm
defines the checking that will be performed by the server to
determine whether the certificate is valid. A validation algorithm
Freeman, et al. Standards Track [Page 7]
RFC 5055 SCVP December 2007
is one of the parameters to a validation policy. SCVP defines a
basic validation algorithm that implements the basic path validation
algorithm as defined in [PKIX-1], and it permits the client to
request additional information about the certificate to be validated.
New validation algorithms can be specified that define additional
checks if needed. These new validation algorithms may specify
additional parameters. The values for these parameters may be
defined by any validation policy that uses the algorithm or may be
included by the client in the request.
Application-specific validation algorithms, in addition to those
defined in this document, can be defined to meet specific
requirements not covered by the basic validation algorithm. The
validation algorithms documented here should serve as a guide for the
development of further application-specific validation algorithms.
For example, a new application-specific validation algorithm might
require the presence of a particular name form in the subject
alternative name extension of the certificate.
1.6. Validation Requirements
For a certification path to be considered valid under a particular
validation policy, it MUST be a valid certification path as defined
in [PKIX-1], and all validation policy constraints that apply to the
certification path MUST be verified.
Revocation checking is one aspect of certification path validation
defined in [PKIX-1]. However, revocation checking is an optional
feature in [PKIX-1], and revocation information is distributed in
multiple formats. Clients specify in requests whether revocation
checking should be performed and whether revocation information
should be returned in the response.
Servers MUST be capable of indicating the sources of revocation
information that they are capable of processing:
1. full CRLs (or full Authority Revocation Lists);
2. OCSP responses, using [OCSP];
3. delta CRLs; and
4. indirect CRLs.
Freeman, et al. Standards Track [Page 8]
RFC 5055 SCVP December 2007
2. Protocol Overview
SCVP uses a simple request-response model. That is, the SCVP client
creates a request and sends it to the SCVP server, and then the SCVP
server creates a single response and sends it to the client. The
typical use of SCVP is expected to be over HTTP [HTTP], but it can
also be used with email or any other protocol that can transport
digitally signed objects. Appendices A and B provide the details
necessary to use SCVP with HTTP.
SCVP includes two request-response pairs. The primary request-
response pair handles certificate validation. The secondary request-
response pair is used to determine the list of validation policies
and default parameters supported by a specific SCVP server.
Section 3 defines the certificate validation request.
Section 4 defines the corresponding certificate validation response.
Section 5 defines the validation policies request.
Section 6 defines the corresponding validation policies response.
Appendix A registers MIME types for SCVP requests and responses, and
Appendix B describes the use of these MIME types with HTTP.
3. Validation Request
An SCVP client request to the server MUST be a single CVRequest item.
When a CVRequest is encapsulated in a MIME body part,
application/scvp-cv-request MUST be used. 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.
The unprotected request consists of a CVRequest encapsulated in a
Cryptographic Message Syntax (CMS) ContentInfo [CMS]. An overview of
this structure is provided below and is only intended as
Freeman, et al. Standards Track [Page 9]
RFC 5055 SCVP December 2007
illustrative. The definitive ASN.1 is found in [CMS]. Many details
are not shown, but the way that SCVP makes use of CMS is clearly
illustrated.
ContentInfo {
contentType id-ct-scvp-certValRequest,
-- (1.2.840.113549.1.9.16.1.10)
content CVRequest }
The protected request consists of a CVRequest encapsulated in either
a SignedData or 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-certValRequest and an eContent field that
contains a Distinguished Encoding Rules (DER)-encoded CVRequest.
SignedData is used when the request is digitally signed.
AuthenticatedData is used with a message authentication code (MAC).
All SCVP clients and servers MUST support SignedData for signed
requests and responses. SCVP clients and servers SHOULD support
AuthenticatedData for MAC-protected requests and responses.
If the client uses SignedData, it MUST have a public key that has
been bound to a subject identity by a certificate that conforms to
the PKIX profile [PKIX-1], and that certificate MUST be suitable for
signing the SCVP request. That is:
1. If the key usage extension is present, either the digital
signature or the non-repudiation bit MUST be asserted.
2. If the extended key usage extension is present, it MUST contain
either the SCVP client OID (see Section 3.11), the
anyExtendedKeyUsage OID, or another OID acceptable to the SCVP
server.
The client MUST put an unambiguous reference to its certificate in
the SignedData that encapsulates the request. The client SHOULD
include its certificate in the request, but MAY omit the certificate
to reduce the size of the request. The client MAY include other
certificates in the request to aid the validation of its certificates
by the SCVP server. The signerInfos field of SignedData MUST include
exactly one SignerInfo. The SignedData MUST NOT include the
unsignedAttrs field.
Freeman, et al. Standards Track [Page 10]
RFC 5055 SCVP December 2007
The client MUST put its key agreement public key, or an unambiguous
reference to a certificate that contains its key agreement public
key, in the AuthenticatedData that encapsulates the request. If an
ephemeral key agreement key pair is used, then the ephemeral key
agreement public key is carried in the originatorKey field of
KeyAgreeRecipientInfo, which requires the client to obtain the
server's key agreement public key before computing the message
authentication code (MAC). An SCVP server's key agreement key is
included in its validation policy response message (see Section 6).
The recipientInfos field of AuthenticatedData MUST include exactly
one RecipientInfo, which contains information for the SCVP server.
The AuthenticatedData MUST NOT include the unauthAttrs field.
The syntax and semantics for SignedData, AuthenticatedData, and
ContentInfo are defined in [CMS]. The syntax and semantics for
CVRequest are defined below. The CVRequest item contains the client
request. The CVRequest contains the cvRequestVersion and query
items; the CVRequest MAY also contain the requestorRef, requestNonce,
requestorName, responderName, requestExtensions, signatureAlg, and
hashAlg items.
The CVRequest MUST have the following syntax:
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }
Conforming clients MUST be able to construct requests with
cvRequestVersion and query. Conforming clients MUST DER encode the
CVRequest in both protected and unprotected messages to facilitate
unambiguous hash-based referencing in the corresponding response
message. 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. Support for the remaining items
is optional in client implementations.
Conforming servers MUST be able to parse CVRequests that contain any
or all of the optional items.
Freeman, et al. Standards Track [Page 11]
RFC 5055 SCVP December 2007
Each of the items within the CVRequest is described in the following
sections.
3.1. cvRequestVersion
The cvRequestVersion item defines the version of the SCVP CVRequest
used in a request. The subsequent response MUST use the same version
number. The value of the cvRequestVersion item MUST be one (1) for a
client implementing this specification. Future updates to this
specification must specify other values if there are any changes to
syntax or semantics. However, new extensions may be defined without
changing the version number.
SCVP clients MUST support asserting this value and SCVP servers MUST
be capable of processing this value.
3.2. query
The query item specifies one or more certificates that are the
subject of the request; the certificates can be either public key
certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query
MUST contain a queriedCerts item as well as one checks item, and one
validationPolicy item; a query MAY also contain wantBack,
responseFlags, serverContextInfo, validationTime, intermediateCerts,
revInfos, producedAt, and queryExtensions items.
A Query MUST have the following syntax:
Query ::= SEQUENCE {
queriedCerts CertReferences,
checks CertChecks,
-- Note: tag [0] not used --
wantBack [1] WantBack OPTIONAL,
validationPolicy ValidationPolicy,
responseFlags ResponseFlags OPTIONAL,
serverContextInfo [2] OCTET STRING OPTIONAL,
validationTime [3] GeneralizedTime OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
producedAt [6] GeneralizedTime OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }
The list of certificate references in the queriedCerts item tells the
server the certificate(s) for which the client wants information.
The checks item specifies the checking that the client wants
performed. The wantBack item specifies the objects that the client
wants the server to return in the response. The validationPolicy
item specifies the validation policy that the client wants the server
Freeman, et al. Standards Track [Page 12]
RFC 5055 SCVP December 2007
to employ. The responseFlags item allows the client to request
optional features for the response. The serverContextInfo item tells
the server that additional information from a previous request-
response is desired. The validationTime item tells the date and time
relative to which the client wants the server to perform the checks.
The intermediateCerts and revInfos items provide context for the
client request. The queryExtensions item provides for future
expansion of the query syntax. The syntax and semantics of each of
these items are discussed in the following sections.
Conforming clients MUST be able to construct a Query with a
queriedCerts item that specifies at least one certificate, checks,
and validationPolicy. Conforming SCVP clients MAY support
specification of multiple certificates and MAY support the optional
items in the Query structure.
SCVP clients that support delegated path discovery (DPD) as defined
in [RQMTS] MUST support wantBack and responseFlags. 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
responseFlags.
Conforming servers MUST be able to process a Query that contains any
of the optional items, and MUST be able to process a Query that
specifies multiple certificates.
3.2.1. queriedCerts
The queriedCerts item is a SEQUENCE of one or more certificates, each
of which is a subject of the request. The specified certificates are
either public key certificates or attribute certificates; if more
than one certificate is specified, all must be of the same type.
Each certificate is either directly included, or it is referenced.
When referenced, a hash value of the referenced item is included to
ensure that the SCVP client and the SCVP server both obtain the same
certificate when the referenced certificate is fetched. Certificate
references use the SCVPCertID type, which is described below. A
single request MAY contain both directly included and referenced
certificates.
CertReferences has the following syntax:
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
Freeman, et al. Standards Track [Page 13]
RFC 5055 SCVP December 2007
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
The ASN.1 definition of Certificate is imported from [PKIX-1] and the
definition of AttributeCertificate is imported from [PKIX-AC].
When creating a SCVPCertID, the certHash is computed over the entire
DER-encoded certificate including the signature. The hash algorithm
used to compute certHash is specified in hashAlgorithm. The hash
algorithm used to compute certHash SHOULD be one of the hash
algorithms specified in the hashAlgorithms item of the server's
validation policy response message.
When encoding SCVPIssuerSerial, serialNumber is the serial number
that uniquely identifies the certificate. For public key
certificates, the issuer MUST contain only the issuer name from the
certificate encoded in the directoryName choice of GeneralNames. For
attribute certificates, the issuer MUST contain the issuer name field
from the attribute certificate.
Conforming clients MUST be able to reference a certificate by direct
inclusion. Clients SHOULD be able to specify a certificate using the
SCVPCertID. Conforming clients MAY be able to reference multiple
certificates and MAY be able to reference both public key and
attribute certificates.
Conforming SCVP Server implementations MUST be able to process
CertReferences with multiple certificates. Conforming SCVP server
implementations MUST be able to parse CertReferences that contain
either public key or attribute certificates. Conforming SCVP server
implementations MUST be able to parse both the cert and pkcRef
choices in PKCReference. Conforming SCVP server implementations that
process attribute certificates MUST be able to parse both the
attrCert and acRef choices in ACReference.
Freeman, et al. Standards Track [Page 14]
RFC 5055 SCVP December 2007
3.2.2. checks
The checks item describes the checking that the SCVP client wants the
SCVP server to perform on the certificate(s) in the queriedCerts
item. The checks item contains a sequence of object identifiers
(OIDs). Each OID tells the SCVP server what checking the client
expects the server to perform. For each check specified in the
request, the SCVP server MUST perform the requested check, or return
an error. A server may choose to perform additional checks (e.g., a
server that is only asked to build a validated certification path may
choose to also perform revocation status checks), although the server
cannot indicate in the response that the additional checks have been
performed, except in the case of an error response.
The checks item uses the CertChecks type, which has the following
syntax:
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
For public key certificates, the following checks are defined in this
document:
- id-stc-build-pkc-path: Build a prospective certification path to a
trust anchor (as defined in Section 6.1 of [PKIX-1]);
- id-stc-build-valid-pkc-path: Build a validated certification path
to a trust anchor (revocation checking not required);
- id-stc-build-status-checked-pkc-path: Build a validated
certification path to a trust anchor and perform revocation status
checks on the certification path.
Conforming SCVP server implementations that support delegated path
discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build-
pkc-path check. Conforming SCVP server implementations that support
delegated path validation (DPV) as defined in [RQMTS] MUST support
the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
path checks.
For attribute certificates, the following checks are defined in this
document:
- id-stc-build-aa-path: Build a prospective certification path to a
trust anchor for the Attribute Certificate (AC) issuer;
- id-stc-build-valid-aa-path: Build a validated certification path
to a trust anchor for the AC issuer;
Freeman, et al. Standards Track [Page 15]
RFC 5055 SCVP December 2007
- id-stc-build-status-checked-aa-path: Build a validated
certification path to a trust anchor for the AC issuer and perform
revocation status checks on the certification path for the AC
issuer;
- id-stc-status-check-ac-and-build-status-checked-aa-path: Build a
validated certification path to a trust anchor for the AC issuer
and perform revocation status checks on the AC as well as the
certification path for the AC issuer.
Conforming SCVP server implementations MAY support the attribute
certificates checks.
For these purposes, the following OIDs are defined:
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-status-checked-pkc-path
OBJECT IDENTIFIER ::= { id-stc 3 }
id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 }
id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 }
id-stc-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 6 }
id-stc-status-check-ac-and-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 7 }
Other specifications may define additional checks.
Conforming client implementations MUST support assertion of at least
one of the standard checks. Conforming clients MAY support assertion
of multiple checks. Conforming clients need not support all of the
checks defined in this section.
3.2.3. wantBack
The optional wantBack item describes any information the SCVP client
wants from the SCVP server for the certificate(s) in the queriedCerts
item in addition to the results of the checks specified in the checks
item. If present, the wantBack item MUST contain a sequence of
object identifiers (OIDs). Each OID tells the SCVP server what the
client wants to know about the queriedCerts item. For each type of
information specified in the request, the server MUST return
information regarding its finding (in a successful response).
Freeman, et al. Standards Track [Page 16]
RFC 5055 SCVP December 2007
For example, a request might include a checks item that only
specifies certification path building and include a wantBack item
that requests the return of the certification path built by the
server. In this case, the response would not include a status for
the validation of the certification path, but it would include a
prospective certification path. A client that wants to perform its
own certification path validation might use a request of this form.
Alternatively, a request might include a checks item that requests
the server to build a certification path and validate it, including
revocation checking, and not include a wantBack item. In this case,
the response would include only a status for the validation of the
certification path. A client that completely delegates certification
path validation might use a request of this form.
The wantBack item uses the WantBack type, which has the following
syntax:
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
For public key certificates, the following wantBacks are defined in
this document:
- id-swb-pkc-cert: The certificate that was the subject of the
request;
- 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-pkc-public-key-info: The public key from the certificate
that was the subject of the request;
- id-swb-pkc-all-cert-paths: A set of certification paths for the
certificate that was the subject of the request;
- id-swb-pkc-ee-revocation-info: Proof of revocation status for the
end entity certificate in the certification path; and
- id-swb-pkc-CAs-revocation-info: Proof of revocation status for
each CA certificate in the certification path.
Freeman, et al. Standards Track [Page 17]
RFC 5055 SCVP December 2007
All conforming SCVP server implementations MUST support the id-swb-
pkc-cert and id-swb-pkc-public-key-info wantBacks. 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.
SCVP provides two methods for a client to obtain multiple
certification paths for a certificate. The client could use
serverContextInfo to request one path at a time (see Section 3.2.6).
After obtaining each path, the client could submit the
serverContextInfo from the previous request to obtain another path
until either the client found a suitable path or the server indicated
(by not returning a serverContextInfo) that no more paths were
available. Alternatively, the client could send a single request
with an id-swb-pkc-all-cert-paths wantBack, in which case the server
would return all of the available paths in a single response.
The server may, at its discretion, limit the number of paths that it
returns in response to the id-swb-pkc-all-cert-paths. When the
request includes an id-swb-pkc-all-cert-paths wantBack, the response
SHOULD NOT include a serverContextInfo.
For attribute certificates, the following wantBacks are defined in
this document:
- id-swb-ac-cert: The attribute certificate that was the subject of
the request;
- id-swb-aa-cert-path: The certification path built for the AC
issuer certificate;
- id-swb-ac-revocation-info: Proof of revocation status for each
certificate in the AC issuer certification path; and
- id-swb-aa-revocation-info: Proof of revocation status for the
attribute certificate.
Conforming SCVP server implementations MAY support the attribute
certificate wantBacks.
The following wantBack can be used for either public key or attribute
certificates:
- id-swb-relayed-responses: Any SCVP responses received by the
server that were used to generate the response to this query.
Conforming SCVP servers MAY support the id-swb-relayed-responses
wantBack.
Freeman, et al. Standards Track [Page 18]
RFC 5055 SCVP December 2007
For these purposes, the following OIDs are defined:
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 }
id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 }
id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 }
id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 }
id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 }
id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10}
id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11}
id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12}
id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13}
id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}
Other specifications may define additional wantBacks.
Conforming client implementations that support delegated path
validation (DPV) as defined in [RQMTS] SHOULD support assertion of at
least one wantBack. Conforming client implementations that support
delegated path discovery (DPD) as defined in [RQMTS] MUST support
assertion of at least one wantBack. Conforming clients MAY support
assertion of multiple wantBacks. Conforming clients need not support
all of the wantBacks defined in this section.
3.2.4. validationPolicy
The validationPolicy item defines the validation policy that the
client wants the SCVP server to use during certificate validation.
If this policy cannot be used for any reason, then the server MUST
return an error response.
A validation policy MUST define default values for all parameters
necessary for processing an SCVP request. For each parameter, a
validation policy may either allow the client to specify a non-
default value or forbid the use of a non-default value. If the
client wishes to use the default values for all of the parameters,
then the client need only supply a reference to the policy in this
item. If the client wishes to use non-default values for one or more
parameters, then the client supplies a reference to the policy plus
whatever parameters are necessary to complete the request in this
item. If there are any conflicts between the policy referenced in
the request and any supplied parameter values in the request, then
the server MUST return an error response.
Freeman, et al. Standards Track [Page 19]
RFC 5055 SCVP December 2007
The syntax of the validationPolicy item is:
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }
The validationPolRef item is required, but the remaining items are
optional. The optional items are used to provide validation policy
parameters. When the client uses the validation policy's default
values for all parameters, all of the optional items are absent.
At a minimum, conforming SCVP client implementations MUST support the
validationPolRef item. Conforming client implementations MAY support
any or all of the optional items in ValidationPolicy.
Conforming SCVP servers MUST support processing of a ValidationPolicy
that contains any or all of the optional items.
The validationAlg item specifies the validation algorithm. The
userPolicySet item provides an acceptable set of certificate
policies. The inhibitPolicyMapping item inhibits certificate policy
mapping during certification path validation. The
requireExplicitPolicy item requires at least one valid certificate
policy in the certificate policies extension. The inhibitAnyPolicy
item indicates whether the anyPolicy certificate policy OID is
processed or ignored when evaluating certificate policy. The
trustAnchors item indicates the trust anchors that are acceptable to
the client. The keyUsages item indicates the technical usage of the
public key that is to be confirmed by the server as acceptable. The
extendedKeyUsages item indicates the application-specific usage of
the public key that is to be confirmed by the server as acceptable.
The syntax and semantics of each of these items are discussed in the
following sections.
3.2.4.1. validationPolRef
The reference to the validation policy is an OID that the client and
server have agreed represents a particular validation policy.
Freeman, et al. Standards Track [Page 20]
RFC 5055 SCVP December 2007
The syntax of the validationPolRef item is:
ValidationPolRef::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
Where a validation policy supports additional policy-specific
parameter settings, these values are specified using the valPolParams
item. The syntax and semantics of the parameters structure are
defined by the object identifier encoded as the valPolId. Where a
validation policy has no parameters, such as the default validation
policy (see Section 3.2.4.1.1), this item MUST be omitted.
Parameters specified in this item are independent of the validation
algorithm and the validation algorithm's parameters (see Section
3.2.4.2). For example, a server may support a validation policy
where it validates a certificate using the name validation algorithm
and also makes a determination regarding the creditworthiness of the
subject. In this case, the validation policy parameters could be
used to specify the value of the transaction. The validation
algorithm parameters are used to specify the application identifier
and name for the name validation algorithm.
Conforming SCVP client implementations MUST support specification of
a validation policy. Conforming SCVP client implementations MAY be
able to specify parameters for a validation policy. Conforming SCVP
server implementations MUST be able to process valPolId and MAY be
able to process valPolParams.
3.2.4.1.1. Default Validation Policy
The client can request the SCVP server's default validation policy or
another validation policy. The default validation policy corresponds
to standard certification path processing as defined in [PKIX-1] with
server-chosen default values (e.g., with a server-determined policy
set and trust anchors). The default values can be distributed out of
band or using the policy request mechanism (see Section 5). This
mechanism permits the deployment of an SCVP server without obtaining
a new object identifier.
The object identifier that identifies the default validation policy
is:
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
Freeman, et al. Standards Track [Page 21]
RFC 5055 SCVP December 2007
The default validation policy MUST use the basic validation algorithm
as its default validation algorithm (see Section 3.2.4.2.1), and has
no validation policy parameters (see Section 3.2.4.1).
When using the default validation policy, the client can override any
of the default parameter values by supplying a specific value in the
request. The SCVP server MUST make use of the provided parameter
values or return an error response.
Conforming implementations of SCVP servers MUST support the default
policy. However, an SCVP server may be configured to send an error
response to all requests using the default policy to meet local
security requirements.
3.2.4.2. validationAlg
The optional validationAlg item defines the validation algorithm to
be used by the SCVP server during certificate validation. The value
of this item can be determined by agreement between the client and
the server. The validation algorithm is represented by an object
identifier.
The syntax of the validationAlg item is:
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }
The following section specifies the basic validation algorithm and
the name validation algorithm.
SCVP servers MUST recognize and support both validation algorithms
defined in this section. SCVP clients that support explicit
assertion of the validation algorithm MUST support the basic
validation algorithm and SHOULD support the name validation
algorithm. Other validation algorithms can be specified in other
documents for use with specific applications. SCVP clients and
servers MAY support any such validation algorithms.
3.2.4.2.1. Basic Validation Algorithm
The client can request use of the SCVP basic validation algorithm or
another algorithm. For identity certificates, the basic validation
algorithm MUST implement the certification path validation algorithm
as defined in Section 6 of [PKIX-1]. For attribute certificates, the
basic validation algorithm MUST implement certification path
validation as defined in Section 5 of [PKIX-AC]. Other validation
algorithms MAY implement functions over and above those in the basic
Freeman, et al. Standards Track [Page 22]
RFC 5055 SCVP December 2007
algorithm, but validation algorithms MUST generate results compliant
with the basic validation algorithm. That is, none of the validation
requirements in the basic algorithm may be omitted from any newly
defined validation algorithms. However, other validation algorithms
MAY reject paths that are valid using the basic validation algorithm.
The object identifier to identify the basic validation algorithm is:
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
When id-svp-basicValAlg appears in valAlgId, the parameters item MUST
be absent.
3.2.4.2.2. Basic Validation Algorithm Errors
The following errors are defined for the basic validation algorithm
for inclusion in the validationErrors item in the response (see
Section 4.9.6). These errors can be used by any other validation
algorithm since all validation algorithms MUST implement the
functionality of the basic validation algorithm.
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 }
id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 }
id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 }
id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 }
The id-bvae-expired value means that the validation time used for the
request was later than the notAfter time in the end certificate (the
certificate specified in the queriedCerts item).
The id-bvae-not-yet-valid value means that the validation time used
for the request was before the notBefore time in the end certificate.
The id-bvae-wrongTrustAnchor value means that a certification path
could not be constructed for the client-specified trust anchor(s),
but a path exists for one of the trust anchors specified in the
server's default validation policy.
The id-bvae-noValidCertPath value means that the server could not
construct a sequence of intermediate certificates between the trust
anchor and the target certificate that satisfied the request.
Freeman, et al. Standards Track [Page 23]
RFC 5055 SCVP December 2007
The id-bvae-revoked value means that the end certificate has been
revoked.
The id-bvae-invalidKeyPurpose value means that the extended key usage
extension ([PKIX-1], Section 4.2.1.13) in the end certificate does
not satisfy the validation policy.
The id-bvae-invalidKeyUsage value means that the keyUsage extension
([PKIX-1], Section 4.2.1.3) in the end certificate does not satisfy
the validation policy. For example, the keyUsage extension in the
certificate may assert only the keyEncipherment bit, but the
validation policy specifies in the keyUsages item that
digitalSignature is required.
The id-bvae-invalidCertPolicy value means that the path is not valid
under any of the policies specified in the user policy set and
explicit policies are required. That is, the valid_policy_tree is
NULL and the explicit_policy variable is zero ([PKIX-1], Section
6.1.5).
3.2.4.2.3. Name Validation Algorithm
The name validation algorithm allows the client to specify one or
more subject names that MUST appear in the end certificate in
addition to the requirements specified for the basic validation
algorithm. The name validation algorithm allows the client to supply
an application identifier and a name to the server. The application
identifier defines the name matching rules to use in comparing the
name supplied in the request with the names in the certificate.
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST
use the NameValidationAlgParms syntax:
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
GeneralNames is defined in [PKIX-1].
If more than one name is supplied in the validationNames value, all
names MUST be of the same type. The certificate must contain a
matching name for each of the names supplied in validationNames
according to the name matching rules associated with the
nameCompAlgId. This specification defines three sets of name
matching rules.
Freeman, et al. Standards Track [Page 24]
RFC 5055 SCVP December 2007
If the nameCompAlgId supplied in the request is id-nva-dnCompAlg,
then GeneralNames supplied in the request MUST be a directoryName,
and the matching rules to be used are defined in [PKIX-1]. The
certificate must contain a matching name in either the subject field
or a directoryName in the subjectAltName extension. This
specification defines the OID for id-nva-dnCompAlg as follows:
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
If the nameCompAlgId supplied in the request is id-kp-serverAuth
[PKIX-1], then GeneralNames supplied in the request MUST be a
dNSName, and the matching rules to be used are defined in [PKIX-1].
If a subjectAltName extension is present and includes one or more
names of type dNSName, a match in any one of the set is considered
acceptable. If the subjectAltName extension is omitted, or does not
include any names of type dNSName, the (most specific) Common Name
field in the subject field of the certificate MUST be used.
Names may contain the wildcard character *, which is considered to
match any single domain name component. That is, *.a.com matches
foo.a.com but not bar.foo.a.com.
If the nameCompAlgId supplied in the request is id-kp-mailProtection
[PKIX-1], then GeneralNames supplied in the request MUST be an
rfc822Name, and the matching rules are defined in [SMIME-CERT].
Conforming SCVP servers MUST support the name validation algorithm
and the matching rules associated with id-nva-dnCompAlg, id-kp-
serverAuth, and id-kp-mailProtection. SCVP servers MAY support other
name matching rules.
3.2.4.2.4. Name Validation Algorithm Errors
The following errors are defined for the name validation algorithm:
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 }
The id-nvae-name-mismatch value means the client supplied a name with
the request, which the server recognized and the server found a
corresponding name type in the certificate, but was unable to find a
Freeman, et al. Standards Track [Page 25]
RFC 5055 SCVP December 2007
match to the name supplied. For example, the client supplied a DNS
name of example1.com, and the certificate contained a DNS name of
example.com.
The id-nvae-no-name value means the client supplied a name with the
request, which the server recognized, but the server could not find
the corresponding name type in the certificate. For example, the
client supplied a DNS name of example1.com, and the certificate only
contained a rfc822Name of user@example.com.
The id-nvae-unknown-alg value means the client supplied a
nameCompAlgId that the server does not recognize.
The id-nvae-bad-name value means the client supplied either an empty
or malformed name in the request.
The id-nvae-bad-name-type value means the client supplied an
inappropriate name type for the application identifier. For example,
the client specified a nameCompAlgId of id-kp-serverAuth, and an
rfc822Name of user@example.com.
The id-nvae-mixed-names value means the client supplied multiple
names in the request of different types.
3.2.4.3. userPolicySet
The userPolicySet item specifies a list of certificate policy
identifiers that the SCVP server MUST use when constructing and
validating a certification path. The userPolicySet item specifies
the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A
userPolicySet containing the anyPolicy OID indicates a user-initial-
policy-set of any-policy.
SCVP clients SHOULD support the userPolicySet item in requests, and
SCVP servers MUST support the userPolicySet item in requests.
3.2.4.4. inhibitPolicyMapping
The inhibitPolicyMapping item specifies an input to the certification
path validation algorithm, and it controls whether policy mapping is
allowed during certification path validation (see [PKIX-1], Section
6.1.1). If the client wants the server to inhibit policy mapping,
inhibitPolicyMapping is set to TRUE in the request. SCVP clients MAY
support inhibiting policy mapping. SCVP servers SHOULD support
inhibiting policy mapping.
Freeman, et al. Standards Track [Page 26]
RFC 5055 SCVP December 2007
3.2.4.5. requireExplicitPolicy
The requireExplicitPolicy item specifies an input to the
certification path validation algorithm, and it controls whether
there must be at least one valid policy in the certificate policies
extension (see [PKIX-1], Section 6.1.1). If the client wants the
server to require at least one policy, requireExplicitPolicy is set
to TRUE in the request.
SCVP clients MAY support requiring explicit policies. SCVP servers
SHOULD support requiring explicit policies.
3.2.4.6. inhibitAnyPolicy
The inhibitAnyPolicy item specifies an input to the certification
path validation algorithm (see [PKIX-1], Section 6.1.1), and it
controls whether the anyPolicy OID is processed or ignored when
evaluating certificate policy. If the client wants the server to
ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the
request.
SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers
SHOULD support ignoring the anyPolicy OID.
3.2.4.7. trustAnchors
The trustAnchors item specifies the trust anchors at which the
certification path must terminate if the path is to be considered
valid by the SCVP server for the request. If a trustAnchors item is
present, the server MUST NOT consider any certification paths ending
in other trust anchors as valid.
The TrustAnchors type contains one or more trust anchor
specifications. A certificate reference can be used to identify the
trust anchor by certificate hash and distinguished name with serial
number. Alternatively, trust anchors can be provided directly. The
order of trust anchor specifications within the sequence is not
important. Any CA certificate that meets the requirements of
[PKIX-1] for signing certificates can be provided as a trust anchor.
If a trust anchor is supplied that does not meet these requirements,
the server MUST return an error response.
The trust anchor itself, regardless of its form, MUST NOT be included
in any certification path returned by the SCVP server.
TrustAnchors has the following syntax:
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
Freeman, et al. Standards Track [Page 27]
RFC 5055 SCVP December 2007
SCVP servers MUST support trustAnchors. SCVP clients SHOULD support
trustAnchors.
3.2.4.8. keyUsages
The key usage extension ([PKIX-1], Section 4.2.1.3) in the
certificate defines the technical purpose (such as encipherment,
signature, and CRL signing) of the key contained in the certificate.
If the client wishes to confirm the technical usage, then it can
communicate the usage it wants to validate by the same structure
using the same semantics as defined in [PKIX-1]. For example, if the
client obtained the certificate in the context of a digital
signature, it can confirm this use by including a keyUsage structure
with the digital signature bit set.
If the keyUsages item is present and contains an empty sequence, it
indicates that the client does not require any particular key usage.
If the keyUsages item contains one or more keyUsage definitions, then
the certificate MUST satisfy at least one of the specified keyUsage
definitions. If the client is willing to accept multiple
possibilities, then the client passes in a sequence of possible
patterns. Each keyUsage can contain a set of one or more bits set in
the request, all bits MUST be set in the certificate to match against
an instance of the keyUsage in the SCVP request. The certificate key
usage extension may contain more usages than requested. For example,
if a client wishes to check for either digital signature or non-
repudiation, then the client provides two keyUsage values, one with
digital signature set and the other with non-repudiation set. If the
key usage extension is absent from the certificate, the certificate
MUST be considered good for all usages and therefore any pattern in
the SCVP request will match.
SCVP clients SHOULD support keyUsages, and SCVP servers MUST support
keyUsages.
3.2.4.9. extendedKeyUsages
The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines
more specific technical purposes, in addition to, or in place of, the
purposes indicated in the key usage extension, for which the
certified public key may be used. If the client will accept
certificates that are consistent with a particular value (or values)
in the extended key usage extension, then it can communicate the
appropriate usages using the same semantics as defined in [PKIX-1].
Freeman, et al. Standards Track [Page 28]
RFC 5055 SCVP December 2007
For example, if the client obtained the certificate in the context of
a Transport Layer Security (TLS) server, it can confirm the
certificate is consistent with this usage by including the extended
key usage structure with the id-kp-serverAuth object identifier.
If the extension is absent, or is present and asserts the
anyExtendedKeyUsage OID, then all usages specified in the request are
a match. If the extension is present and does not assert the
anyExtendedKeyUsage OID, all usages in the request MUST be present in
the certificate. The certificate extension may contain more usages
than requested.
Where the client does not require any particular extended key usage,
the client can specify an empty SEQUENCE. This may be used to
override extended key usage requirements imposed in the validation
policy specified by valPolId.
SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST
support extendedKeyUsages.
3.2.4.10. specifiedKeyUsages
The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines
more specific technical purposes, in addition to or in place of the
purposes indicated in the key usage extension, for which the
certified public key may be used. If the client requires that a
particular value (or values) appear in the extended key usage
extension, then it can specify the required usage(s) using the same
semantics as defined in [PKIX-1]. For example, if the client
obtained the certificate in the context of a TLS server, it might
require that the server certificate include the extended key usage
structure with the id-kp-serverAuth object identifier. In this case,
the client would include a specifiedKeyUsages item in the request and
assert the id-kp-serverAuth object identifier.
If one or more specified usages are included in the request, the
certificate MUST contain the extended key usage extension, and all
usages specified in the request MUST be present in the certificate
extension. The certificate extension may contain more usages than
specified in the request. Specified key usages are not satisfied by
the presence of the anyExtendedKeyUsage OID.
Where the client does not require any particular extended key usage,
the client can specify an empty SEQUENCE. This may be used to
override specified key usage requirements imposed in the validation
policy specified by valPolId.
Freeman, et al. Standards Track [Page 29]
RFC 5055 SCVP December 2007
SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST
support specifiedKeyUsages.
3.2.5. responseFlags
The optional responseFlags item allows the client to indicate which
optional features in the CVResponse it wants the server to include.
If the default values for all of the flags are used, then the
responseFlags item MUST NOT be included in the request.
The syntax of the responseFlags item is:
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }
Each of the response flags is described in the following sections.
3.2.5.1. fullRequestInResponse
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. The main reason a
client would request the server to include the full request in the
response is to archive the request-response exchange in a single
object. That is, the client wants to archive a single object that
includes both request and response.
SCVP clients and servers MUST support the default behavior. SCVP
clients MAY support requesting and processing the full request. SCVP
servers SHOULD support returning the full request.
3.2.5.2. responseValidationPolByRef
The responseValidationPolByRef item controls whether the response
includes just a reference to the policy or a reference to the policy
plus all the parameters by value of the policy used to process the
request. The response MUST contain a reference to the validation
policy. If the client wants the validation policy parameters to be
included by value also, then responseValidationPolByRef is set to
FALSE. The main reason a client would request the server to include
validation policy to be included by value is to archive the request-
response exchange in a single object. That is, the client wants to
archive the CVResponse and have it include every aspect of the
validation policy.
Freeman, et al. Standards Track [Page 30]
RFC 5055 SCVP December 2007
SCVP clients MUST support requesting and processing the validation
policy by reference, and SCVP servers MUST support returning the
validation policy by reference. SCVP clients MAY support requesting
and processing the validation policy by values. SVCP servers SHOULD
support returning the validation policy by values.
3.2.5.3. protectResponse
The protectResponse item indicates whether the client requires the
server to protect the response. If the client is performing full
certification path validation on the response and it is not concerned
about the source of the response, then the client does not benefit
from a digital signature or MAC on the response. In this case, the
client can indicate to the server that protecting the message is
unnecessary. However, the server is always permitted to return a
protected response.
SCVP clients that support delegated path discovery (DPD) as defined
in [RQMTS] MUST support setting this value to FALSE.
SCVP clients that support delegated path validation (DPV) as defined
in [RQMTS] require an authenticated response. Unless a protected
transport mechanism (such as 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, and SCVP
servers SHOULD support returning unprotected responses. Based on
local policy, the server can be configured to return protected or
unprotected responses if this value is set to FALSE. If, based on
local policy, the server is unable to return protected responses,
then the server MUST return an error if this value is set to TRUE.
3.2.5.4. cachedResponse
The cachedResponse item indicates whether the client will accept a
cached response. To enhance performance and limit the exposure of
signing keys, an SCVP service may be designed to cache responses
until new revocation information is expected. Where cachedResponse
is set to TRUE, the client will accept a previously cached response.
Clients may insist on creation of a fresh response to protect against
a replay attack and ensure that information is up to date. Where
cachedResponse is FALSE, the client will not accept a cached
response. To ensure that a response is fresh, the client MUST also
include the requestNonce as defined in Section 3.4.
Freeman, et al. Standards Track [Page 31]
RFC 5055 SCVP December 2007
Servers MUST process the cachedResponse flag. Where cachedResponse
is FALSE, servers that cannot produce fresh responses MUST reply with
an error message. Servers MAY choose to provide fresh responses even
where cachedResponse is set to TRUE.
3.2.6. serverContextInfo
The optional serverContextInfo item, if present, contains context
from a previous request-response exchange with the same SCVP server.
It allows the server to return more than one certification path for
the same certificate to the client. For example, if a server
constructs a particular certification path for a certificate, but the
client finds it unacceptable, the client can then send the same query
back to the server with the serverContextInfo from the first
response, and the server will be able to provide a different
certification path (if another one can be found).
Contents of the serverContextInfo are opaque to the SCVP client.
That is, the client only knows that it needs to return the value
provided by the server with the subsequent request to get a different
certification path. Note that the subsequent query needs to be
identical to the previous query with the exception of the following:
- requestNonce,
- serverContextInfo, and
- the client's digital signature or MAC on the request.
SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD
support serverContextInfo.
3.2.7. validationTime
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. If the validationTime is present, it MUST be
encoded as GeneralizedTime. The validationTime provided MUST be a
retrospective time since the server can only perform a validity check
using the current time (default) or previous time. A server can
ignore the validationTime provided in the request if the time is
within the clock skew of the server's current time.
Freeman, et al. Standards Track [Page 32]
RFC 5055 SCVP December 2007
The revocation status information is obtained with respect to the
validation time. When specifying a validation time other than the
current time, the validation time should not necessarily be identical
to the time when the private key was used. The validation time
specified by the client may be adjusted to compensate for:
1) time for the end-entity to realize that its private key has been,
or could possibly be, compromised, and/or
2) time for the end-entity to report the key compromise, and/or
3) time for the revocation authority to process the revocation
request from the end-entity, and/or
4) time for the revocation authority to update and distribute the
revocation status information.
GeneralizedTime values MUST be expressed in Universal Coordinated
Time (UTC) (which is also known as Greenwich Mean Time and Zulu time)
and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when
the number of seconds is zero. GeneralizedTime values MUST NOT
include fractional seconds.
The information in the corresponding CertReply item in the response
MUST be formatted as if the server created the response at the time
indicated in the validationTime. However, if the server does not
have appropriate historical information, the server MUST return an
error response.
SCVP servers MUST apply a clock skew to the validation time to allow
for minor time synchronization errors. The default value is 10
minutes. If the server uses a value other than the default, it MUST
include the clock skew value in the validation policy response.
SCVP clients MAY support validationTime other than the current time.
SCVP servers MUST support using its current time, and SHOULD support
the client setting the validationTime in the request.
3.2.8. intermediateCerts
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. When building certification paths, the server
MAY use the certificates in the intermediateCerts item in addition to
any other certificates that the server can access. When present, the
intermediateCerts item MUST contain at least one certificate, and
Freeman, et al. Standards Track [Page 33]
RFC 5055 SCVP December 2007
the intermediateCerts item MUST be structured as a CertBundle. The
certificates in the intermediateCerts item MUST NOT be considered as
valid by the server just because they are present in this item.
The CertBundle type contains one or more certificates. The order of
the entries in the bundle is not important. CertBundle has the
following syntax:
CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate
SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST
support intermediateCerts.
3.2.9. revInfos
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. Note that the
information in the revInfos item might not be used by the server.
For example, the revocation information might be associated with
certificates that the server does not use in the certification path
that it constructs.
Clients SHOULD be courteous to the SCVP server by separating CRLs and
delta CRLs. However, since the two share a common syntax, SCVP
servers SHOULD accept delta CRLs even if they are identified as
regular CRLs by the SCVP client.
CRLs, delta CRLs, and OCSP responses can be provided as revocation
information. If needed, additional object identifiers can be
assigned for additional revocation information types in the future.
The revInfos item uses the RevocationInfos type, which has the
following syntax:
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
Freeman, et al. Standards Track [Page 34]
RFC 5055 SCVP December 2007
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
3.2.10. producedAt
The client MAY allow the server to use a cached SCVP response. When
doing so, the client MAY use the producedAt item to express
requirements on the freshness of the cached response. The producedAt
item tells the earliest date and time at which an acceptable cached
response could have been produced. The producedAt item represents
the date and time in UTC, using the GeneralizedTime type. The value
in the producedAt item is independent of the validation time.
GeneralizedTime value MUST be expressed in UTC, as defined in Section
3.2.7.
SCVP clients MAY support using producedAt values in the request.
SCVP servers MAY support the producedAt values in the request. SCVP
servers that support cached responses SHOULD support the producedAt
value in requests.
3.2.11. queryExtensions
The optional queryExtensions item contains extensions. If present,
each extension in the sequence extends the query. 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 queryExtensions 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.2.11.1. extnID
The extnID item is an identifier for the extension. It contains the
object identifier that names the extension.
3.2.11.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
that it does not recognize; however, a non-critical extension MAY be
ignored if it is not recognized, but MUST be processed if it is
recognized.
Freeman, et al. Standards Track [Page 35]
RFC 5055 SCVP December 2007
3.2.11.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.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
Freeman, et al. Standards Track [Page 36]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 37]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 38]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 39]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 40]
RFC 5055 SCVP December 2007
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 }
Freeman, et al. Standards Track [Page 41]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 42]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 43]
RFC 5055 SCVP December 2007
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),
Freeman, et al. Standards Track [Page 44]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 45]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 46]
RFC 5055 SCVP December 2007
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.
Freeman, et al. Standards Track [Page 47]
RFC 5055 SCVP December 2007
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 retu |
