Internet Draft A. Malpani
draft-ietf-pkix-scvp-09.txt ValiCert, Inc
June 2002 R. Housley
Expires in six months RSA Laboratories
T. Freeman
Microsoft Corp
Simple Certificate Validation Protocol (SCVP)
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
SCVP allows a client to offload certificate handling to a server. The
server can prove the client with a variety of valuable information
about the certificate, such as whether the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize trust and policy management.
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
Malpani, Housley, & Freeman [Page 1]
INTERNET DRAFT SCVP June 2002
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 application wants just two things. First, they
want confirmation that the public key belongs to the identity named
in the certificate. Second, they want to know if the public key can
be used for the intended purpose. The client delegates certificate
validation to the SCVP server.
The second class of application can perform certification path
validation, but these applications have no reliable method of
constructing a certification path to a trust anchor. The client
delegates certification path construction to the SCVP server.
1.1 SCVP overview and requirements
The SCVP meets the requirements documented in [RQMTS].
The primary goals of SCVP are to make it easier for applications to
deploy PKI-enables systems and to allow central administration of an
organization's PKI policies. 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. 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
enterprise.
Untrusted SCVP servers can provide clients the certification paths.
They can also provide clients revocation information, such as CRLs
and OCSP responses, that the client needs to validate the
certification path constructed by the SCVP server. These services can
be valuable to clients that do not include 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 uses these services, the
client inherently trusts the SCVP server as much as it would its own
path validation software (if it contained such software). There are
two main reasons that a client may want to trust such an SCVP server:
- The client does not want to incur the overhead of including
certification path validation software and running it for each
certificate it receives.
Malpani, Housley, & Freeman [Page 2]
INTERNET DRAFT SCVP June 2002
- The client is in an enterprise that wants to centralize its PKI
policies. These policies might dictate which trust anchors are
used and the types of policy checking that are performed during
certification path validation.
1.2 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 [MUSTSHOULD].
1.3 Open Issues
The following is a list of issues that were raised on earlier
versions of this document that have not been fully dealt with here.
Comments on these issues are particularly welcome.
- Extensions can be marked as critical. The usefulness and
problems of criticality have been long debated and there has not
been a great deal of consensus. In SCVP, marking a request
extension as critical says to the server "don't give me an
answer unless you understand this extension", and marking a
response extension as critical says "don't use this response
unless you understand this extension". Without the critical bit
in the extensions, either the semantics of extensions would have
to be changed to essentially say "all extensions are critical"
(which is overkill for some extensions that might really be
optional), or the semantics would have to be changed to say "you
can never rely on the other party understanding an extension",
which would limit the usefulness of some extensions.
- Should we allow another way of specifying trust anchors? If so,
it needs to include (1) the trusted issuer name, (2) the trusted
public key algorithm, (3) the trusted public key, and (4)
optionally, the trusted public key parameters associated with
the public key.
- Is there any value to an "unvalidated path"?
- The structure allows for the validation of other objects, such
as attribute certificates, to be easily added as Query CHOICE
items. Should we change the name of the protocol to reflect
this flexibility?
- Can CertBundle contain objects of a different type than the
object being queried? For example, if the client wants the
server to validate a public key certificate, can the CertBundle
contain an attribute certificate?
Malpani, Housley, & Freeman [Page 3]
INTERNET DRAFT SCVP June 2002
- Can TrustedCerts contain objects of a different type than the
object being queried? For example, if, in the future, the
client wants the server to validate a attribute certificate, can
the CertBundle contain a public key certificate?
- Should TrustedCerts contain constraints? For example, should
the client be able to impose name constraints (or other
constraints) on a particular trust anchor.
- Should we require the certReplies SEQUENCE items to be listed in
a particular order?
- ReplyTypesOfCheck and ReplyWantBack use the Extensions
structure. What does the critical bit mean? Should a different
structure be used?
- There was a request for an OPTIONAL field in the request to
provide input values to the path validation algorithm. Two are
explicit: trust anchors and policies. The validation policy
implicitly supplies the rest. Does this adequately address the
need?
- TODO: Show how to delegate SCVP signing authority.
- TODO: Add extensions to allow client to require server to
validate a certificate for a particular context, such as
SSL/TLS, S/MIME, or IPsec.
- TODO: Allow the response to be unsigned if it is simply
reporting an error. Generating malformed requests should not
force the server to perform a private key operation.
- TODO: Change the structure of RequestHash to be algorithm
identifier followed by hash value. This will allow any
one-way hash algorithm to be used.
- TODO: Move error codes that apply to the whole request up a
level.
2 Protocol
The SCVP protocol 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. Typical use of SCVP is expected to be over HTTP, and possibly
email. In Appendix B, this document registers MIME types for SCVP
requests and responses.
Malpani, Housley, & Freeman [Page 4]
INTERNET DRAFT SCVP June 2002
Section 3 defines the certificate validation request, and section 4
defines the corresponding response.
Section 5 defines the validation policies request and the
corresponding response.
3 Validation Request
A SCVP client request to the server MUST be a single SCVPRequest
item. When a SCVPRequest is encapsulated in a MIME body part,
application/scvp-request MUST be used.
There are two forms of SCVP request: unsigned and signed. A signed
request can be used to authenticate the client to the server. A
server MAY require all requests to be signed, and a server MAY
discard all unsigned requests. Alternatively, a server MAY choose to
process unsigned requests.
The unsigned request consists of a PSRequest encapsulated in a
ContentInfo.
ContentInfo {
contentType id-ct-scvp-psRequest,
-- (1.2.840.113549.1.9.16.1.10)
content PSRequest }
The signed request consists of a PSRequest encapsulated in a
SignedData which is in turn encapsulated in a ContentInfo.
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData }
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- (Optional)
crls CertificateRevocationLists, -- (Optional)
signerInfos SET OF SignerInfos } -- (only one in SCVP)
SignerInfo {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- (Required)
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
Malpani, Housley, & Freeman [Page 5]
INTERNET DRAFT SCVP June 2002
unsignedAttrs UnsignedAttributes } -- (not used in SCVP)
EncapsulatedContentInfo {
eContentType id-ct-scvp-psRequest,
-- (1.2.840.113549.1.9.16.1.10)
eContent OCTET STRING } -- Contains PSRequest
The syntaxes for SignedData and ContentInfo are defined in [CMS]. The
syntax for PSRequest is defined below. The PSRequest item contains
the client request. The "PS" in PSRequest means "possibly signed".
The PSRequest item contains scvpVersion, query, typesOfCheck, and
wantBack items. It MAY also contain a requestor, requestNonce, and
reqExtensions items.
The scvpVersion item MUST contain the integer one (1).
The query item MUST contain a Query. This specification includes only
the CertsQuery; however, the use of a CHOICE permits future versions
of this protocol to support validation of other objects.
The typesOfCheck item MUST contain a sequence of object identifiers.
Each object identifier tells the server what types of checking the
client expects the server to perform on the on the query item(s).
The wantBack item MUST contain a sequence of object identifiers. Each
object identifier tells the server what the client wants to know
about the query item(s).
The requestor item MAY contain an octet string. If present, the octet
string contains a locally generated identifier of the client. No
provisions are made to ensure uniqueness of the requestor octet
string.
The requestNonce item MAY contain an octet string. If present, the
octet string MUST contain an identifier generated by the client for
the request.
The reqExtensions item MAY contain Extensions. If present, each
Extension in the sequence extends the request. For example, an
Extension MAY be used to request a different type of item.
The PSRequest MUST have the following syntax:
PSRequest ::= SEQUENCE {
scvpVersion INTEGER,
query Query,
checks CertChecks,
wantBack WantBack,
Malpani, Housley, & Freeman [Page 6]
INTERNET DRAFT SCVP June 2002
requestor [0] OCTET STRING OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
reqExtensions [2] Extensions OPTIONAL }
3.1 scvpVersion
The scvpVersion item tells the version of SCVP used in a request or a
response. The value of the scvpVersion item MUST be one (1). Updates
to this specification ought to specify other integer values.
3.2 Query
The Query specifies one or more items, and these items are the object
of the request. One type of object is defined in this specification:
CertsQuery. However, other types of queries can be specified in the
future. The CertsQuery is a request for information regarding one or
more certificates. A CertsQuery MUST contain a sequence of one or
more certificate reference. A CertsQuery MAY also contain
serverContextInfo, validityTime, intermediateCerts, trustedCerts,
revInfos, certPolicies, configID, and queryExtensions items. Query
MUST have the following syntax:
Query ::= CHOICE {
certsQuery [0] CertsQuery }
CertsQuery ::= SEQUENCE {
queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference,
serverContextInfo [0] OCTET STRING OPTIONAL,
validityTime [1] GeneralizedTime OPTIONAL,
intermediateCerts [2] CertBundle OPTIONAL,
trustedCerts [3] CertBundle OPTIONAL,
revInfos [4] RevocationInfos OPTIONAL,
certPolicies [5] CertPolicyIDs OPTIONAL,
configID [6] OBJECT IDENTIFIER OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }
The list of certificate references in the Query item tells the server
the certificate(s) for which the client wants information. The
optional serverContextInfo item tells the server that additional
information from a previous request-response in desired. The optional
validityTime item tells the date and time relative to which the
client wants the server to perform the checks. The optional
intermediateCerts, trustedCerts, revInfos, certPolicies, and configID
items provide context for the client request.
3.2.1 queriedCerts
The queriedCerts item, using the CertReference type, MUST contain at
Malpani, Housley, & Freeman [Page 7]
INTERNET DRAFT SCVP June 2002
least one certificate reference. The CertReference contains either
the certificate or a reference to the certificate. Certificate
references use the ESSCertID type defined in [ESS]. CertReference has
the following syntax:
CertReference ::= CHOICE {
pkixCert [1] Certificate,
certId [2] ESSCertID }
The ASN.1 definition of Certificate is imported from [PKIX]. The
definition of ESSCertID is imported from [ESS].
3.2.2 serverContextInfo
The serverContextInfo item, if present, contains context from a
previous request-response transaction with the same 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 one
can be found).
Contents of the serverContextInfo are opaque to the 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 be
essentially identical to the previous query. The client MUST NOT
change any items other than:
- requestNonce
- serverContextInfo
- the client's signature on the request
3.2.3 validityTime
The optional validityTime item tells the date and time relative to
which the client wants the server to perform the checks. If the
validityTime is present, it MUST be encoded as GeneralizedTime. If
the validityTime is not present, the server MUST respond as if the
client provided the at which the server processes the request.
GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)
and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
where the number of seconds is zero. GeneralizedTime values MUST NOT
include fractional seconds.
The information in the corresponding CertReply item in the response
Malpani, Housley, & Freeman [Page 8]
INTERNET DRAFT SCVP June 2002
MUST be formatted as if the server created the response at the time
indicated in the validityTime. However, if the server does not have
appropriate historical information, the server MAY either return an
error or return information for a later time. A client MUST be
prepared to handle responses that contain thisUpdate items that do
not match the requested validityTime.
3.2.4 intermediateCerts
The intermediateCerts item helps the server create valid
certification paths. The intermediateCerts item, when present,
provides certificates that the server MAY use when forming a
certification path. The certificates in the intermediateCerts item
MAY be used by the server in addition to any other certificates that
the server can access when building certification paths. The
intermediateCerts item, when present, MUST contain at least one
certificate. The intermediateCerts item MUST be structured as a
CertBundle. The certificates in the intermediateCerts MUST NOT be
trusted by the server just because they are present in this item.
The CertBundle type contains one or more certificate references. The
order of the entries in the bundle is not important. CertBundle has
the following syntax:
CertBundle ::= SEQUENCE SIZE (1..MAX) OF CertReference
3.2.5 trustedCerts
The trustedCerts item optionally specifies the trust anchors to be
used by the server. If a trustedCerts item is present, the server
MUST NOT use any certification path trust anchors other than those
provided. The trustedCerts item MUST be structured as a CertBundle
(see section 3.3.4).
3.2.6 revInfos
The revInfo item optionally specifies revocation information such as
CRLs [PKIX] and OCSP responses [OCSP] that the 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 (for example, 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, such as if the
information is for certificates that the server does not use in
certification path building.
The types of revocation information that can be provided are: a CRL
or an OCSP response.
Malpani, Housley, & Freeman [Page 9]
INTERNET DRAFT SCVP June 2002
The revInfos item uses the RevocationInfos type, which has the
following syntax:
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
The object identifiers for riType for CRLs and OCSP are id-ri-crl and
id-ri-ocsp-response, respectively.
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 16 }
id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
3.2.7 certPolicies
The certPolicies optional item specifies a list of policy identifiers
that the server MUST use when forming and validating a certification
path.
If certPolicies is not specified, then the policy any-policy is used.
The certPolicies item uses the CertPolicyIDs type, which has the
following syntax:
CertPolicyIDs ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
3.2.8 configID
The configID item, when present, tells the server the SCVP options
that the client wants the server to use. The client can use this
option instead of specifying other SCVP configuration items such as
certPolicies and trustedCerts. The value of this item is determined
by private agreement between the client and the server, but it MUST
be represented as an OBJECT IDENTIFIER. The server might want to
assign identifiers that indicate that some settings are used in
addition to others given in the request. In this way, the
configuration identifier might be a shorthand for some SCVP options,
but not others.
3.2.9 queryExtensions
The queryExtensions item specifies a list of extensions to the SCVP
Malpani, Housley, & Freeman [Page 10]
INTERNET DRAFT SCVP June 2002
protocol. For example, a client might request additional information
about the certificate(s) in the CertsQuery. The syntax for Extensions
is imported from [PKIX]. The queryExtensions item, when present,
contains a sequence of Extension items, each of which contains an
extnID item, a critical item, and an extnValue item.
The extnID item is an identifier for the extension. It contains the
object identifier (OID) of the extension.
The critical item is a BOOLEAN that tells whether the extension is
critical. The values for the item are:
- FALSE (Not critical)
- TRUE (Critical)
In a request, if the critical item is TRUE, the server MUST NOT
process the request unless it understands the extension. In a reply,
if the critical item is TRUE, the client MUST NOT process the
response unless it understands the extension.
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 extnID).
3.3 checks
The checks item describes the checking that the client wants the
server to perform on the certificate(s) in the query item. If the
checks item is present in a request, it can contain one or more types
of check. For each type of check specified in the request, the server
MUST perform all the checks requested, or return an error.
Revocation status checking inherently includes path construction.
Also, building a validated certification path does not imply
revocation status checks (although a server may still choose to
perform them).
The checks item uses the CertChecks type, which has the following
syntax:
CertChecks ::= SEQUENCE {
pathChecks SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER,
valPolicy ValidationPolicy OPTIONAL }
3.3.1 pathChecks
The pathChecks item contains a list of object identifiers (OIDs) that
describes the checking that the client wants the server to perform on
the certificate(s) in the query item.
Malpani, Housley, & Freeman [Page 11]
INTERNET DRAFT SCVP June 2002
OIDs are defined for these types of checks:
- Build a certification path to a trusted root.
- Build a validated certification path to a trusted root.
- Do revocation status checks on the certification path.
For these purposes, the following OIDs are defined:
id-stc OBJECT IDENTIFIER ::= { id-pkix 17 }
id-stc-build-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-valid-status-checked-path
OBJECT IDENTIFIER ::= { id-stc 3 }
3.3.2 valPolicy
The valPolicy item defines the validation policy to be used during
certificate validation.
The valPolicy item uses the ValidationPolicy type, which has the
following syntax:
ValidationPolicy ::= SEQUENCE {
valPolicyId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valPolicyId OPTIONAL }
If no validation policy is specified in the request, then the default
validation policy is used. The default validation policy may also be
explicitly specified. The OBJECT IDENTIFIER to identify 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 }
The meaning of this policy is:
- Trust anchors will come from the trustedCerts field. If no
certificates are specified in the trustedCerts field, then
the server may use trust anchors of its own choosing.
- The acceptable policy set will come from the certPolicies field.
If no policy is specified there, then any-policy is used.
3.4 wantBack
Malpani, Housley, & Freeman [Page 12]
INTERNET DRAFT SCVP June 2002
The wantBack item describes the kind of information the client wants
from the server for the certificate(s) in the Query item. The
wantBack item MUST contain one or more types of information. For each
type of information specified in the request, the server MUST return
information regarding its finding (in a successful response).
For example, a request might include a typesOfCheck 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
certification path that the server considers to be valid. A client
that wants to perform its own 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
The types of information that can be requested are:
- Certification path built for the certificate
- Proof of revocation status
For these purposes, the following OIDs are defined:
id-swb OBJECT IDENTIFIER ::= { id-pkix 18 } -- SCVP want back
id-swb-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
3.5 requestor
The requestor optional item is used to identify the requestor. The
value is only of local significance to the requestor. If the client
includes a requestor value in the request, then the server MUST
return the same value in the response.
The requestor item uses the OCTET STRING type.
3.6 requestNonce
The requestNonce optional item contains an identifier generated by
the client for the request. If the client includes a requestNonce
value in the request, then the server MUST return the same value in
the response. The client SHOULD include a requestNonce item in every
request to prevent an attacker acting as a man-in-the-middle by
replaying old responses from the server. The requestNonce value
Malpani, Housley, & Freeman [Page 13]
INTERNET DRAFT SCVP June 2002
SHOULD change with every request sent by the client.
The requestNonce item uses the OCTET STRING type.
3.7 reqExtensions
The reqExtensions optional item specifies a list of extensions to the
request. The reqExtensions item contains a sequence of Extension
items, each of which contains an extnID item, a critical item, and an
extnValue item.
The syntax and semantics of these items are described in section
3.2.9.
4 Validation Response
A SCVP server response to the client MUST be a single SCVPResponse
item. A SCVPRequest item is carried in an application/scvp-response
MIME body part.
There are two forms of an SCVP response: unsigned and signed. An
unsigned MUST only be generated for an error status. An unsigned
response is as follows:
ContentInfo {
contentType id-ct-scvp-psResponse,
-- (1.2.840.113549.1.9.16.1.11)
content PSResponse }
The signed response consists of a PSResponse encapsulated in a
SignedData which is in turn encapsulated in a ContentInfo. A signed
response is as follows:
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData }
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- (Optional)
crls CertificateRevocationLists, -- (Optional)
signerInfos SET OF SignerInfos } -- Only 1 in SCVP
SignerInfo {
version CMSVersion,
sid SignerIdentifier,
Malpani, Housley, & Freeman [Page 14]
INTERNET DRAFT SCVP June 2002
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- (Required)
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes } -- Not used in SCVP
EncapsulatedContentInfo {
eContentType id-ct-scvp-psResponse,
-- (1.2.840.113549.1.9.16.1.11)
eContent OCTET STRING } -- Contains PSResponse
The signedAttrs within SignerInfo MUST include SigningCertificate
attribute as defined in [ESS]. The first certificate identified in
the sequence of certificate identifiers MUST be the certificate of
the SCVP server. The inclusion of other certificate identifiers is
OPTIONAL. The inclusion of policies is also OPTIONAL.
The PSResponse item contains the server response. The PSResponse
MUST contain scvpVersion, producedAt, responseStatus, and requestRef
items. The PSResponse MAY also contain requestor, responder,
replyObjects, requestNonce, serverContextInfo, and respExtensions
optional items. The replyObjects item MUST contain exactly one
CertReply item for each certificate requested. The requestor and the
responder items MUST be included if the request included a requestor
item. The requestNonce item MUST be included if the request included
a requestNonce item.
The PSResponse MUST have the following syntax:
PSResponse ::= SEQUENCE {
scvpVersion INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
requestRef RequestReference,
requestor [1] OCTET STRING OPTIONAL,
responder [2] OCTET STRING OPTIONAL,
replyObjects [3] ReplyObjects OPTIONAL,
requestNonce [4] OCTET STRING OPTIONAL,
serverContextInfo [5] OCTET STRING OPTIONAL,
respExtensions [6] Extensions OPTIONAL }
4.1 scvpVersion
The syntax and semantics of the scvpVersion item is described in
section 3.1.
4.2 producedAt
Malpani, Housley, & Freeman [Page 15]
INTERNET DRAFT SCVP June 2002
The producedAt item tells the date and time at which the server
generated the response. The producedAt item represents the date and
time in UTC.
The producedAt item uses the GeneralizedTime type.
GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu)
and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
where the number of seconds is zero. GeneralizedTime values MUST NOT
include fractional seconds.
This rule for GeneralizedTime applies to all occurrences of
GeneralizedTime in this specification and is the same as the rule
used in certificate profiles [PKIX].
4.3 responseStatus
The responseStatus item gives status information to the 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 optionally be used to transmit status information. The
client MAY choose to display the string to the human user. However,
because there is no way to know the languages understood by the human
user, the string may be of little or no use to them.
The responseStatus item uses the ResponseStatus type, which has the
following syntax:
ResponseStatus ::= SEQUENCE {
statusCode SCVPStatusCode,
errorMessage [0] UTF8String OPTIONAL }
SCVPStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignature (24),
unableToDecode (25),
notAuthorized (26) }
The meaning of the various SCVPStatusCode values are:
Malpani, Housley, & Freeman [Page 16]
INTERNET DRAFT SCVP June 2002
0 The request was fully processed
1 The request included unrecognized items; continuing
10 Too busy; try again later
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; aborting
23 The key given in the RequestSignature is not recognized
24 The signature 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 items; continuing
28 The request included unsupported items; aborting
4.4 requestReference
The requestRef allows the server to identify the request that
corresponds to this response. It ties the response to a particular
request using a hash of the request or a copy of PSRequest from the
request.
The requestRef item does not provide authentication, but the
requestRef does allow the client to determine that the request was
not maliciously modified.
When using connectionless protocols, the requestRef item allows the
client to associate a response with a request. (Although, the
requestNonce provides a better mechanism for matching requests and
responses.) Also, 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 OCTET STRING, -- hash of PSRequest
fullRequest PSRequest }
4.4.1 requestHash
The requestHash item is the SHA-1 hash of the PSRequest. 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. (Although, the requestNonce provides a
better mechanism for matching requests and responses.)
Malpani, Housley, & Freeman [Page 17]
INTERNET DRAFT SCVP June 2002
The requestHash item uses the OCTET STRING type.
4.4.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 PSRequest type. The syntax and
semantics of the PSRequest type are described in section 3.
4.5 requestor
The requestor optional item is used to identify the requestor. The
value is only of local significance to the requestor. If the client
includes a requestor value in the request, then the server MUST
return the same value in the response.
The requestor item uses the OCTET STRING type.
4.6 responder
The responder optional item is used to identify the server. The value
chosen is only of local significance to the server. The responder
items MUST be included if the request included a requestor item.
The responder item uses the OCTET STRING type.
4.7 replyObjects
The replyObjects item returns requested objects to the client. In
this specification, the replyObjects item is always a certReplies,
which is a sequence of CertReply, each of which tells the client
about a single certificate from the request. The CertReply item MUST
contain cert, replyStatus, and thisUpdate items, and it MAY contain a
nextUpdate item. The CertReply MAY also contain the
replyTypesOfCheck, replyWantBack, and singleReplyExtensions optional
items.
The typesOfCheck, wantBack, and queryExtension items in the request
control the presence or absence of the replyTypesOfCheck,
replyWantBack, and singleReplyExtensions optional items in the
response. A server MUST include one of the above items for each
related item requested in the typesOfCheck, and wantBack items.
The replyObjects item uses the ReplyObjects type, which has the
following syntax:
Malpani, Housley, & Freeman [Page 18]
INTERNET DRAFT SCVP June 2002
ReplyObjects ::= CHOICE {
certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply }
CertReply ::= SEQUENCE {
cert Certificate,
replyStatus ReplyStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] GeneralizedTime OPTIONAL,
replyTypesOfCheck [1] Extensions OPTIONAL,
replyWantBack [2] Extensions OPTIONAL,
singleReplyExtensions [3] Extensions OPTIONAL }
4.7.1 cert
The cert item contains the certificate about which the client is
requesting information.
The cert item uses the Certificate type, which is defined in [PKIX].
4.7.2 replyStatus
The replyStatus item gives status information to the client about the
request for the specific certificate. Note that the responseStatus
item is different than the replyStatus item. The responseStatus item
is the status of the whole request, while the replyStatus item is the
status for the individual query item.
The replyStatus item uses the ReplyStatus type, which has the
following syntax:
ReplyStatus ::= ENUMERATED {
success (0),
certTypeUnrecognized (1),
typeOfCheckUnrecognized (2),
wantBackUnrecognized (3),
certMalformed (4),
policyIDUnrecognized (5),
configInfoUnrecognized (6) }
The meaning of the various ReplyStatus values are:
0 Success: a definitive answer follows
1 Failure: the certificate type is not recognized
2 Failure: an item wanted in TypesOfCheck is not recognized
3 Failure: an item wanted in WantBack is not recognized
4 Failure: the certificate was malformed
5 Failure: the mandatory PolicyID is not recognized
6 Failure: the ConfigurationIdentifier is not recognized
Malpani, Housley, & Freeman [Page 19]
INTERNET DRAFT SCVP June 2002
7 Failure: unauthorized request
8 Failure: unsupported validation policy
Status code 4 is used to tell the client that the request was
properly formed but the certificate in question was not. This is
useful to clients that cannot parse a certificate.
4.7.3 thisUpdate
The ThisUpdate item tells the time at which the information in the
CertReply was correct. The thisUpdate item represents the date and
time in UTC.
The thisUpdate item uses the GeneralizedTime type. The encoding rules
for GeneralizedTime in section 4.2 MUST be used.
4.7.4 nextUpdate
The nextUpdate item tells the time at which the server expects
additional information regarding the validity of the certificate to
become available. Such information could change the status of the
certificate; however, it might not change the status of the
certificate. The nextUpdate item represents the date and time in UTC.
The nextUpdate item uses the GeneralizedTime type. The encoding rules
for GeneralizedTime in section 4.2 MUST be used.
4.7.5 replyTypesOfCheck
The replyTypesOfCheck contains the responses to the typesOfCheck item
in the request. The replyTypesOfCheck item uses the Extensions type.
The syntax of the Extensions type is discussed in section 3.2.9. The
object identifiers (OIDs) in the typesOfCheck item in the request are
used to identify the corresponding reply value. The OIDs in the
replyTypesOfCheck item MUST match the OIDS in the typesOfCheck item
in the request. The criticality bit MUST NOT be set.
The value for path building to a trusted root, {type-arc 0}, can be
one of the following:
Value Meaning
----- -------
0 Built a path
1 Could not build a path
The value for path validation to a trusted root, {type-arc 1}, can be
one of the following:
Malpani, Housley, & Freeman [Page 20]
INTERNET DRAFT SCVP June 2002
Value Meaning
----- -------
0 Valid
1 Not valid
The value for the revocation status, {type-arc 2}, can be one of the
following:
Value Meaning
----- -------
0 Good
1 Revoked
2 Unknown
4.7.6 replyWantBack
The replyWantBack contains the responses to the wantBack item in the
request. The replyWantBack item uses the Extensions type. The syntax
of the Extensions type is discussed in section 3.2.9. The object
identifiers (OIDs) in the wantBack item in the request are used to
identify the corresponding reply value. The OIDs in the replyWantBack
item MUST match the OIDS in the wantBack item in the request. The
criticality bit MUST NOT be set.
The extnValue for the certification chain used to verify the
certificate in the request, {want-arc 0}, uses the CertBundle type.
The syntax and semantics of the CertBundle type are described in
section 3.2.4.
The extnValue for the proof of revocation status, {want-arc 1}, uses
the RevocationInfo type. The syntax and semantics of the
RevocationInfo type are described in section 3.2.6.
4.7.7 singleReplyExtensions
The singleReplyExtensions contains the responses to the
queryExtension item in the request. The singleReplyExtensions item
uses the Extensions type. The syntax of the Extensions type is
discussed in section 3.2.9. The object identifiers (OIDs) in the
queryExtension item in the request are used to identify the
corresponding reply value. The OIDs in the queryExtension item MUST
match the OIDS in the singleReplyExtensions item in the request. The
criticality bit MUST NOT be set.
4.8 requestNonce
The requestNonce optional item contains an identifier generated by
the client for the request. If the client includes a requestNonce
Malpani, Housley, & Freeman [Page 21]
INTERNET DRAFT SCVP June 2002
value in the request, then the server MUST return the same value in
the response.
The requestNonce item uses the OCTET STRING type.
4.9 serverContextInfo
The serverContextInfo item in a response is a mechanism for the
server to pass some opaque context information to the client. If the
client does not like the path retuned, it can make a new query and
pass along this context information.
Section 3.2.2 contains information about the client usage of this
item.
The context information is opaque to the client, but it provides
information to the server that ensures that a different certification
path will be returned (if possible). The context information could
indicate state on the server or it could contain a sequence of hashes
of certification paths that have already returned to the client. The
protocol does not dictate any structure or requirements for this
item. (Implementers should review the Security Considerations section
of this document before selecting a structure.)
Servers that are incapable of returning additional paths MUST NOT
include the serverContextInfo item in the response.
4.10 respExtensions
The respExtensions optional item specifies a list of extensions to
the response. The respExtensions item contains a sequence of
Extension items, each of which contains an extnID item, a critical
item, and an extnValue item.
The syntax and semantics of these items are described in section
3.2.9.
5 Validation Policies
A SCVP server also needs to be able to inform a client about the
validation policies it supports. For this purpose, SCVP defines a
simple request-response pair.
5.1 Validation Policies Request
A SCVP client request to the server to ask about the validation
policies it supports be a single ValPoliciesRequest item. When a
ValPoliciesRequest is encapsulated in a MIME body part, it MUST be
Malpani, Housley, & Freeman [Page 22]
INTERNET DRAFT SCVP June 2002
carried in an application/scvp-policies-request MIME body part.
The request consists of a ValPoliciesRequest encapsulated in a
ContentInfo.
ContentInfo {
contentType id-ct-scvp-valPolRequest,
-- (1.2.840.113549.1.9.16.1.12)
content ValPoliciesRequest }
The ValPoliciesRequest type has the following syntax:
ValPoliciesRequest ::= SEQUENCE {
scvpVersion INTEGER }
The scvpVersion item is described in section 3.1.
5.2 Validation Policies Response
In response to a ValPoliciesRequest, the server provides a
ValPoliciesResponse. When a ValPoliciesResponse is encapsulated in a
MIME body part, it MUST be carried in an application/scvp-policies-
response MIME body part.
The request consists of a ValPoliciesRequest encapsulated in a
ContentInfo.
ContentInfo {
contentType id-ct-scvp-valPolResponse,
-- (1.2.840.113549.1.9.16.1.13)
content ValPoliciesResponse }
The ValPoliciesResponse type has the following syntax:
ValPoliciesResponse ::= SEQUENCE {
scvpVersion INTEGER,
valPolicies SEQUENCE OF OBJECT IDENTIFIER }
The scvpVersion item is described in section 3.1.
The valPolicies item contains a sequence of object identifiers
(OIDs). Each OID identifies a single validation policy supported by
the server.
6 ASN.1 Syntax for SCVP
This section defines the syntax for SCVP messages. The semantics for
Malpani, Housley, & Freeman [Page 23]
INTERNET DRAFT SCVP June 2002
the messages are defined in sections 3, 4, and 5. The SCVP ASN.1
module follows.
SCVP DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier, Certificate, Extensions, Name
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1) }
ContentInfo, SignedData
FROM CryptographicMessageSyntax -- RFC 2630
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms(1) }
ESSCertID
FROM ExtendedSecurityServices -- RFC 2634
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) ess(2) };
<TBD>
END
7 Security Considerations
A client that trusts a server's response for validation of a
certificate inherently trusts that server as much as it would trust
its own validation software. This means that if an attacker
compromises a trusted SCVP server, the attacker can change the
validation processing for every client that relies on that server.
Thus, an SCVP server must be protected at least as well as the trust
anchors that the SCVP server trusts.
Clients MUST check the requestHash in the response and ensure that it
matches their original request. Requests contain a lot of information
that affects the response and clients need to ensure that the server
response corresponds to the expected request.
When the SCVP response is used to determine the validity of a
certificate, the client MUST validate the signature on the response
to ensure that the expected SCVP server generated it. If the client
Malpani, Housley, & Freeman [Page 24]
INTERNET DRAFT SCVP June 2002
does not check the signature on the response, a man-in-the-middle
attack could fool the client into believing modified responses from
the server, or responses to questions the client did not ask.
If the client does not include a requestNonce item, or if the client
does not check that the requestNonce in the reply matches that in the
request, an attacker can replay previous responses from the server.
If the server does not require some sort of authorization (such as
signed requests), an attacker can get the server to reply to
arbitrary requests. Such responses may give the attacker information
about weaknesses in the server or about the timeliness of the
server's checking. This information may be valuable for a future
attack.
If the server uses the serverContextInformation to indicate some
server state associated with a requestor, implementers must take
appropriate measures against denial of service attacks where an
attacker sends in a lot of requests at one time to force the server
to keep a lot of state information.
The request and response for which policies are supported on the
server are unsigned. These could lead to a denial of service attack
where a man in the middle indicates that a server supports
additional/less policies than it actually does. This could result in
the client requesting validation based on a policy the server does
not support of lead the client using a less desirable policy than it
would prefer to.
8 References
Normative and informative references are provided.
8.1 Normative References
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and
C. Adams, "X.509 Internet Public Key Infrastructure -
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[PKIX] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and
Malpani, Housley, & Freeman [Page 25]
INTERNET DRAFT SCVP June 2002
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[SHA-1] National Institute of Standards and Technology,
"Secure Hash Standard", NIST FIPS Pub 180-1, April 1995.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
8.2 Informative References
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RQMTS] Pinkas, D., and R. Housley, "Delegated Path Validation
and Delegated Path Discovery Protocol Requirements",
<draft-ietf-pkix-dpv-dpd-req-05.txt>.
9 Acknowledgments
The lively debate in the PKIX Working Group also had a significant
impact this protocol. Denis Pinkas suggested some additional
requirements for the protocol, and Mike Myers identified areas that
needed clarification. Frank Balluffi and Ameya Talwalkar did an
implementation based on an early draft of this protocol, and they
identified a few deficiencies. John Thielens and Peter Sylvester
provided a lot of good input that improved this document.
Appendix A -- MIME Registrations
Four MIME type registrations are provided in this appendix.
A.1 application/scvp-request
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-request
MIME media type name: application
MIME subtype name: scvp-request
Required parameters: format
Optional parameters: None
Encoding considerations: binary
Malpani, Housley, & Freeman [Page 26]
INTERNET DRAFT SCVP June 2002
Security considerations: Carries a request for information. This
request may optionally be cryptographically signed.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Simple
Certificate Validation Protocol (SCVP)
Applications which use this media type: SCVP clients
Additional information:
Magic number(s): None
File extension(s): .SCQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
A.2 application/scvp-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-response
MIME media type name: application
MIME subtype name: scvp-response
Required parameters: format
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographically signed response
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Simple
Certificate Validation Protocol (SCVP)
Applications which use this media type: SCVP servers
Malpani, Housley, & Freeman [Page 27]
INTERNET DRAFT SCVP June 2002
Additional information:
Magic number(s): None
File extension(s): .SCS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
A.3 application/scvp-policies-request
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-policies-request
MIME media type name: application
MIME subtype name: scvp-policies-request
Required parameters: format
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a request for information.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Simple
Certificate Validation Protocol (SCVP)
Applications which use this media type: SCVP clients
Additional information:
Magic number(s): None
File extension(s): .SPQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Malpani, Housley, & Freeman [Page 28]
INTERNET DRAFT SCVP June 2002
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
A.4 application/scvp-policies-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-policies-response
MIME media type name: application
MIME subtype name: scvp-policies-response
Required parameters: format
Optional parameters: None
Encoding considerations: Binary
Security considerations: None
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Simple
Certificate Validation Protocol (SCVP)
Applications which use this media type: SCVP servers
Additional information:
Magic number(s): None
File extension(s): .SPP
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Appendix B -- SCVP over HTTP
This appendix describes the formatting conventions for the SCVP
request and response when carried by HTTP.
B.1 SCVP Request
Malpani, Housley, & Freeman [Page 29]
INTERNET DRAFT SCVP June 2002
HTTP based SCVP requests can use the POST method to submit their
requests. Where privacy is a requirement, SCVP transactions exchanged
using HTTP MAY be protected using either TLS/SSL or some other lower
layer protocol.
An SCVP request using the POST method is constructed as follows:
The Content-Type header MUST have the value "application/scvp-
request". The Content-Length header MUST be present and have the
exact length of the request. The body of the message is the binary
value of the DER encoding of the FullRequest. Other HTTP headers
MAY be present and MAY be ignored if not understood by the
requestor.
Sample Content-Type headers are:
Content-Type: application/scvp-request
B.2 SCVP Response
An HTTP-based SCVP response is composed of the appropriate HTTP
headers, followed by the binary value of the DER encoding of the
FullResponse. The Content-Type header MUST have the value
"application/scvp-response". The Content-Length header MUST be
present and specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.
Appendix C -- Author Contact Information
Ambarish Malpani
ValiCert, Inc.
1215 Terra Bella Ave.
Mountain View, CA 94043
USA
ambarish@valicert.com
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
rhousley@rsasecurity.com
Trevor Freeman
Microsoft Corporation,
One Microsoft way
Redmond, WA 98052
USA
trevorf@microsoft.com
Malpani, Housley, & Freeman [Page 30]
INTERNET DRAFT SCVP June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the
ASN.1 modules presented in Appendices A and B may be used in whole or
in part without inclusion of the copyright notice. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Malpani, Housley, & Freeman [Page 31]
