One document matched: draft-ietf-pkix-scvp-12.txt
Differences from draft-ietf-pkix-scvp-11.txt
Internet Draft A. Malpani
draft-ietf-pkix-scvp-12.txt Malpani Consulting Services
June 2003 R. Housley
Expires in six months Vigil Security
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 provide 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 revocation
status. SCVP has many purposes, including simplifying client
implementations and allowing companies to centralize trust and
policy management.
INTERNET DRAFT SCVP June 2003
Table of Contents
1 Introduction......................................................4
1.1 SCVP overview and requirements................................4
1.2 Terminology...................................................5
1.3 Validation Policies...........................................5
2 Protocol Overview.................................................6
3 Validation Request................................................6
3.1 scvpVersion...................................................8
3.2 Query.........................................................8
3.2.1 queriedCerts..............................................9
3.2.2 checks....................................................9
3.2.3 wantBack.................................................11
3.2.4 serverContextInfo........................................12
3.2.5 valPolicy................................................12
3.2.6 validityTime.............................................14
3.2.7 trustAnchors.............................................15
3.2.8 intermediateCerts........................................16
3.2.9 revInfos.................................................16
3.2.10 queryExtensions.........................................17
3.3 Requestor....................................................17
3.4 requestNonce.................................................17
3.5 reqExtensions................................................18
4 Validation Response..............................................18
4.1 scvpVersion..................................................20
4.2 producedAt...................................................21
4.3 responseStatus...............................................21
4.4 requestReference.............................................22
4.4.1 requestHash..............................................22
4.4.2 fullRequest..............................................23
4.5 Requestor....................................................23
4.6 responder....................................................23
4.7 replyObjects.................................................24
4.7.1 cert.....................................................24
4.7.2 replyStatus..............................................25
4.7.3 replyValTime.............................................26
4.7.4 replyChecks..............................................26
4.7.5 replyWantBack............................................27
4.7.6 valPolicy................................................28
4.7.7 nextUpdate...............................................29
4.7.8 certReplyExtensions......................................29
4.8 requestNonce.................................................29
4.9 serverContextInfo............................................29
4.10 respExtensions..............................................30
5 Validation Policies Request......................................30
6 Validation Policies Response.....................................31
7 SCVP Server Relay................................................31
8 SCVP ASN.1 Module................................................32
9 Security Considerations..........................................37
10 References......................................................38
10.1 Normative References........................................38
Malpani, Housley, & Freeman [Page2]
INTERNET DRAFT SCVP June 2003
10.2 Informative References......................................39
11 Acknowledgments.................................................39
Appendix A -- MIME Registrations...................................39
A.1 application/scvp-request.....................................39
A.2 application/scvp-response....................................40
A.3 application/scvp-policies-request............................41
A.4 application/scvp-policies-response...........................42
Appendix B -- SCVP over HTTP.......................................42
B.1 SCVP Request.................................................42
Appendix C -- Author Contact Information...........................43
Malpani, Housley, & Freeman [Page3]
INTERNET DRAFT SCVP June 2003
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 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 to deploy PKI-
enabled applications and to allow central administration of PKI
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 revocation information, such as CRLs
and OCSP responses, and 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
Malpani, Housley, & Freeman [Page4]
INTERNET DRAFT SCVP June 2003
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.
- The client is in an organization or community 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 [STDWORDS].
1.3 Validation Policies
A validation policy can be used to specify the SCVP configuration.
The validation policy is determined by private agreement between the
client and the server, but it MUST be represented as an OBJECT
IDENTIFIER. The SCVP server can assign identifiers that indicate
that some settings are used in addition to values provided in the
SCVP request. These values might include certificate policies and
trust anchors.
In a separate, yet to be written, document application-specific
validation policies will be defined. These validation policies
should serve as guides for the development of further application-
specific validation policies. S/MIME, IPsec, and TLS likely
candidate applications for this document.
For a certification path to meet the 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]. Therefore, the validation policy MUST specify
the source of revocation information. Five alternatives are
envisioned:
1. full CRLs (or full Authority Revocation Lists) have to be
collected;
2. OCSP responses, using [OCSP], have to be collected;
3. delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected;
Malpani, Housley, & Freeman [Page5]
INTERNET DRAFT SCVP June 2003
4. any available revocation information has to be collected;
and
5. no revocation information need be collected.
2 Protocol Overview
The 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, but it can also
be used with email. Appendix A and Appendix 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 supported by a specific SCVP server.
Section 3 defines the certificate validation request, and section 4
defines the corresponding response.
Section 5 defines the validation policies request, and section 6
defines the corresponding 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
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 certValRequest encapsulated in a
ContentInfo. An overview of this structure 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-certValRequest,
-- (1.2.840.113549.1.9.16.1.10)
content CVRequest }
Malpani, Housley, & Freeman [Page6]
INTERNET DRAFT SCVP June 2003
The signed request consists of a certValRequest encapsulated in
either a SignedData or AuthenticatedData which is in turn
encapsulated in a ContentInfo. An overview of this structure is
provided below. Again, many details are not shown, but the way that
SCVP makes use of CMS is clearly illustrated.
SignedData example:
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,
unsignedAttrs UnsignedAttributes } -- (not used in SCVP)
AuthenticatedData example:
ContentInfo {
contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2)
content AuthenticatedData }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
-- Not used in SCVP
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
Malpani, Housley, & Freeman [Page7]
INTERNET DRAFT SCVP June 2003
MessageAuthenticationCode ::= OCTET STRING
EncapsulatedContentInfo {
eContentType id-ct-scvp-certValRequest,
-- (1.2.840.113549.1.9.16.1.10)
eContent OCTET STRING } -- Contains CVRequest
The syntaxes for SignedData, AuthenticatedData and ContentInfo are
defined in [CMS]. The syntax for CVRequest is defined below. The
CVRequest item contains the client request. The CVRequest item
contains the scvpVersion and query items; and the CVRequest item MAY
also contain the requestor, requestNonce, and reqExtensions items.
The CVRequest MUST have the following syntax:
CVRequest ::= SEQUENCE {
scvpVersion INTEGER,
query Query,
requestor [0] OCTET STRING OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
reqExtensions [2] Extensions OPTIONAL }
Each of the items within the CVRequest are described in the
following sections.
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).
Future updates to this specification ought to specify other integer
values.
3.2 Query
The query specifies one or more certificates that are the object of
the request; the certificates can be either public key certificates
[PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain
a sequence of one or more certificate references, checks, and
wantBack items; and a query MAY also contain valPolicy, validityTime,
trustAnchors, intermediateCerts, revInfos, and queryExtensions items.
Query MUST have the following syntax:
Query ::= SEQUENCE {
queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference,
checks CertChecks,
wantBack WantBack,
serverContextInfo [0] OCTET STRING OPTIONAL,
valPolicy [1] ValidationPolicy,
validityTime [2] GeneralizedTime OPTIONAL,
Malpani, Housley, & Freeman [Page8]
INTERNET DRAFT SCVP June 2003
trustAnchors [3] TrustAnchors OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
queryExtensions [6] 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
valPolicy, trustAnchors, intermediateCerts, and revInfos items
provide context for the client request. The OPTIONAL
queryExtensions item provides for future expansion of the query
syntax.
3.2.1 queriedCerts
The queriedCerts item, using the CertReference type, identifies the
certificate that is the object of the request. The certificate is
either a public key certificate or an attribute certificate. The
certificate is either directly included or it is referenced. When
referenced, a SHA-1 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 ESSCertID type defined in [ESS]. CertReference
has the following syntax:
CertReference ::= CHOICE {
pkc PKCReference,
ac ACReference }
PKCReference ::= CHOICE {
cert [1] Certificate,
pkcRef [2] ESSCertID }
ACReference ::= CHOICE {
attrCert [3] AttributeCertificate,
acRef [4] ESSCertID }
The ASN.1 definition of Certificate is imported from [PKIX-1]; the
definition of AttributeCertificate is imported from [PKIX-AC]; and
the definition of ESSCertID is imported from [ESS].
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 MUST contain a sequence of object identifiers.
Each object identifier tells the SCVP server what checking the
Malpani, Housley, & Freeman [Page9]
INTERNET DRAFT SCVP June 2003
client expects the server to perform. For each check specified in
the request, the SCVP server MUST perform all of the requested
checks, 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 revocation status checks).
The checks item uses the CertChecks type, which has the following
syntax:
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
A list of object identifiers (OIDs) indicates the checking that the
client wants the SCVP server to perform on the certificate(s) in the
queriedCerts item.
For public key certificates, OIDs are defined for the following
checks:
- Build a certification path to a trusted root;
- Build a validated certification path to a trusted root; and
- Do revocation status checks on the certification path.
For attribute certificates, OIDs are defined for the following
checks:
- Build a certification path to a trusted root for the AC issuer;
- Build a validated certification path to a trusted root for the
AC issuer;
- Do revocation status checks on the certification path for the AC
issuer; and
- Do revocation status checks on the AC as well as the
certification path for the AC issuer.
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
Malpani, Housley, & Freeman [Page10]
INTERNET DRAFT SCVP June 2003
OBJECT IDENTIFIER ::= { id-stc 7 }
3.2.3 wantBack
The wantBack item describes the kind of information the SCVP client
wants from the SCVP server for the certificate(s) in the
queriedCerts item. The wantBack item MUST contain a sequence of
object identifiers. Each object identifier 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).
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
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.
Alternatively, a request might include a checks item that requests
the server to build a certification path and validate it, including
revocation checking, and include a wantBack item that requests the
return of the status. 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 types of information that can be
requested are:
- Certification path built for the certificate;
- Proof of revocation status for each certificate in the
certification path;
- Status indication; and
- Public key from the certificate.
For attribute certificates, the types of information that can be
requested are:
- Certification path built for the AC issuer certificate;
- Proof of revocation status for each certificate in the AC
issuer certification path;
- Proof of revocation status for the attribute certificate; and
- Status indication.
Malpani, Housley, & Freeman [Page11]
INTERNET DRAFT SCVP June 2003
For these purposes, the following OIDs are defined:
id-swb OBJECT IDENTIFIER ::= { id-pkix 18 } -- SCVP want back
id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 }
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-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 }
3.2.4 serverContextInfo
The serverContextInfo item, if present, contains context from a
previous request-response transaction 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
be essentially identical to the previous query. The client MUST NOT
change any items other than:
- requestNonce;
- serverContextInfo; and
- the client's signature on the request
3.2.5 valPolicy
The valPolicy item, defines the validation policy to be used by the
SCVP server during certificate validation. The client can use this
instead of specifying other SCVP configuration items such as
trustAnchors. The value of this item can be 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
validation policy object identifier can be a shorthand for some SCVP
options, but not others.
Malpani, Housley, & Freeman [Page12]
INTERNET DRAFT SCVP June 2003
The valPolicy item uses the ValidationPolicy type, which has the
following syntax:
ValidationPolicy ::= SEQUENCE {
valPolicyId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valPolicyId OPTIONAL }
The client can request the SCVP server's default validation policy
is used or another policy. 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 }
All SCVP servers MUST support the default policy.
The meaning of the default validation policy is:
- Trust anchors will come from the trustAnchors item. If no
certificates are specified in the trustAnchors item, then the
SCVP server will use trust anchors of its own choosing.
- The acceptable policy set will come from the certPolicies item
associated with the selected trust anchor. If no certificate
policies are specified in the certPolicies item, then the SCVP
server will use any-policy.
- The SCVP server will check for certificate revocation using
CRLs, delta CRLs, OCSP responses, or any other source of
revocation information that is available.
3.2.5.1 Name Validation Policy
The name validation policy allows the client to supply a name to the
server along with a application identifier. The application
identifier defines the name matching rules use to compare the name
supplied in the request with the names in the certificate being
validated.
id-svp-NameValPol OBJECT IDENTIFIER ::= { id-svp 2 }
NameValidation ::= SEQUENCE {
KeyPurposeId OBJECT IDENTIFIER,
ValidationName GeneralName }
KeyPurposeId and GeneralName are defined in [PKIX-1].
Malpani, Housley, & Freeman [Page13]
INTERNET DRAFT SCVP June 2003
If the KeyPurposeID supplied in the request is id-kp-serverAuth
[PKIX-1] then GeneralName supplied in the request MUST be a DNS name,
and the matching rules to be used are defined in [HTTP-TLS].
If the KeyPurposeID supplied in the request is id-kp-mailProtection
[PKIX-1] then GeneralName supplied in the request MUST be a rfc822
name, and the matching rule MUST be a case insensitive whole sting
comparison. For example user@foo.com matches USER@FOO.COM, but not
auser@foo.com or user@afoo.com
3.2.5.2 Name Validation Policy Errors
The following errors are defined for the Name Validation Policy
id-nvpe OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 }
id-nvpe-NameMismatch OBJECT IDENTIFIER ::= { id-nvpe 1 }
id-nvpe-NoCertName OBJECT IDENTIFIER ::= { id-nvpe 2 }
id-nvpe-UnknownPupose OBJECT IDENTIFIER ::= { id-nvpe 3 }
id-nvpe-BadName OBJECT IDENTIFIER ::= { id-nvpe 4 }
id-nvpe-BadNameType OBJECT IDENTIFIER ::= { id-nvpe 5 }
Name mismatch means the client supplied a name with the validation
policy, which the server recognized and the server found
corresponding name type in the certificate, but was unable to find a
match to the name supplied. For example the client supplied a DNS
name of foo.com, the certificate contained a DNS name of bar.com.
NoCertName means the client supplied a name with the validation
policy, 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 foo.com, the certificate only
contained a rfc822 name of user@bar.com.
UnknownPupose means the client supplied KeyPurposeID which the
server does not recognize.
BadName means the client supplied either and empty or malformed name
in the request.
BadNameType means the client supplied an inappropriate name type for
the key purpose. For example the client specified a key purpose ID
of id-kp-serverAuth, and a rfc822 name of user@foo.com.
3.2.6 validityTime
The OPTIONAL validityTime item tells the date and time relative to
which the SCVP 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 perform the
Malpani, Housley, & Freeman [Page14]
INTERNET DRAFT SCVP June 2003
using the date and time at which the server processes the request.
The validityTime provided MUST be retrospective since the server can
only perform a validity check using the current time (default) or
previous time.
GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)
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 validityTime. However, if the server does not have
appropriate historical information, the server MUST return an error.
3.2.7 trustAnchors
The OPTIONAL trustAnchors item specifies the trust anchors to be
used by the SCVP server. One or more certificate policy MAY be
associated with each trust anchor. If a trustAnchors item is
present, the server MUST NOT use any certification path trust
anchors other than those provided.
The TrustAnchors type contains one or more trust anchor
specification. A certificate reference can be used to identify the
trust anchor distinguished name, public key algorithm, associated
public key parameters, if needed, and the trusted public key.
Alternatively, these items can be provided directly. The order of
trust anchor specifications within the sequence is not important.
The OPTIONAL certPolicies item specifies a list of policy
identifiers that the SCVP server MUST use when forming and
validating a certification path that terminates at the associated
trust anchor. If certPolicies is not specified, then any-policy
MUST be used.
The trust anchor itself, regardless of its form, MUST NOT be
included in any certification path constructed by the SCVP server.
TrustAnchors has the following syntax:
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor
TrustAnchor ::= SEQUENCE {
anchor PKCReference,
certPolicies [1] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL }
-- if absent, use any-policy
Malpani, Housley, & Freeman [Page15]
INTERNET DRAFT SCVP June 2003
3.2.8 intermediateCerts
The OPTIONAL intermediateCerts item helps the SCVP server create
valid certification paths. The intermediateCerts item, when present,
provides certificates that the server MAY use when forming a
certification path. The 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 PKCReference
3.2.9 revInfos
The OPTIONAL revInfo 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 (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. For example, the revocation information might be associated
with certificates that the server does not use in certification path
building.
It is courteous to the SCVP server to separate 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,
Malpani, Housley, & Freeman [Page16]
INTERNET DRAFT SCVP June 2003
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
retype OBJECT IDENTIFIER,
revalue ANY DEFINED BY retype }
3.2.10 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 extension MUST
contain extnID, critical, and extnValue items.
The extnID item is an identifier for the extension. It contains the
object identifier that names the extension.
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). An SCVP server MUST reject the query if it encounters a
critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized.
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 Requestor
The OPTIONAL requestor item is used to identify the requestor. The
value is only of local significance to the requestor. If the SCVP
client includes a requestor value in the request, then the SCVP
server MUST return the same value in the response.
The requestor item MUST be an octet string. No provisions are made
to ensure uniqueness of the requestor octet string; however, all of
the octets MUST have values other than zero.
3.4 requestNonce
The OPTIONAL requestNonce item contains an identifier generated by
the SCVP 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 from
acting as a man-in-the-middle by replaying old responses from the
Malpani, Housley, & Freeman [Page17]
INTERNET DRAFT SCVP June 2003
server. The requestNonce value SHOULD change with every request
sent by the client.
The requestNonce item MUST be an octet string.
3.5 reqExtensions
The OPTIONAL reqExtensions 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 the SCVP. The
syntax for Extensions is imported from [PKIX-1]. The reqExtensions
item, when present, MUST contain a sequence of extension items, and
each of extension MUST contain extnID, critical, and extnValue items.
The extnID item is an identifier for the extension. It contains the
object identifier that names the extension.
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). An SCVP server MUST reject the query if it encounters a
critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized.
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.
4 Validation Response
A SCVP server response to the client MUST be a single SCVPResponse
item. A SCVPResponse item is carried in an application/scvp-
response MIME body part.
There are two forms of an SCVP response: unsigned and signed. An
unsigned response MUST only be generated for an error status. An
overview of the structure used for an unsigned response is provided
below. Many details are not shown, but the way that SCVP makes use
of CMS is clearly illustrated.
ContentInfo {
contentType id-ct-scvp-certValResponse,
-- (1.2.840.113549.1.9.16.1.11)
content CVResponse }
The signed response consists of a CVResponse encapsulated in either
a SignedData or a AuthenticatedData which is in turn encapsulated in
a ContentInfo. An overview of the structure used for a signed
response is provided below. Again, many details are not shown, but
the way that SCVP makes use of CMS is clearly illustrated.
Malpani, Housley, & Freeman [Page18]
INTERNET DRAFT SCVP June 2003
Signed Data Example:
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData }
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- (MUST include server cert)
crls CertificateRevocationLists, -- (Optional)
signerInfos SET OF SignerInfos } -- Only 1 in SCVP
SignerInfo {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- (Required)
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes } -- Not used in SCVP
AuthenticatedData Example:
ContentInfo {
contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2)
content AuthenticatedData }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
-- Not used in SCVP
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING
EncapsulatedContentInfo {
eContentType id-ct-scvp-psResponse,
Malpani, Housley, & Freeman [Page19]
INTERNET DRAFT SCVP June 2003
-- (1.2.840.113549.1.9.16.1.11)
eContent OCTET STRING } -- Contains CVResponse
The SCVP server MUST include its own certificate in the certificates
field within SignedData. Other certificates can also be included.
The SCVP server MAY also provide one or more CRLs in the crls field
within SignedData.
The signedAttrs within SignerInfo MUST include the content-type and
message-digest attributes defined in [CMS] as well as the
SigningCertificate attribute as defined in [ESS]. Within the
SigningCertificate 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 SigningCertificate attribute is OPTIONAL. The inclusion of
policies in the SigningCertificate attribute is also OPTIONAL.
The value of the message-digest attribute in the signedAttrs within
SignerInfo MAY be used as an identifier of the reponse generated by
the SCVP server.
The CVResponse item contains the server response. The CVResponse
MUST contain the scvpVersion, producedAt, responseStatus, and
requestRef items. The CVResponse MAY also contain the 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 CVResponse MUST have the following syntax:
CVResponse ::= 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.
Malpani, Housley, & Freeman [Page20]
INTERNET DRAFT SCVP June 2003
4.2 producedAt
The producedAt item tells the date and time at which the SCVP server
generated the response. The producedAt item represents the date and
time in UTC, using 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.
4.3 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 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 assistance.
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),
internalError (12),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignature (24),
unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignature (29),
invalidSignature (30),
relayingLoop (40) }
The SCVPStatusCode values have the following meaning:
Malpani, Housley, & Freeman [Page21]
INTERNET DRAFT SCVP June 2003
0 The request was fully processed
1 The request included some unrecognized items; however,
processing was able to continue ignoring them
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, and the server was
not able to continue processing
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 checks items, and the server
was not able to continue processing
28 The request included unsupported want back items, and the
server was not able to continue processing
29 The server does not support the signature algorithm used by
the client to sign the request
30 The server could not validate the client's signature on the
request
40 The request was previously relayed by the same server
4.4 requestReference
The requestRef allows the SCVP server to identify the request that
corresponds to this response. It associates the response to a
particular request using a hash of the request or a copy of
CVRequest 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. However, the
requestNonce provides a better 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 [1] HashValue, -- hash of CVRequest
fullRequest [2] CVRequest }
4.4.1 requestHash
Malpani, Housley, & Freeman [Page22]
INTERNET DRAFT SCVP June 2003
The requestHash item is the hash of the CVRequest. By default, SHA-
1 is used as the one-way hash function, but others can be used.
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. However, the requestNonce provides
a better mechanism for matching requests and responses.
The requestHash item uses the HashValue type, which has the
following syntax:
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { 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.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 CVRequest type. The syntax and
semantics of the PSRequest type are described in section 3.
4.5 Requestor
The OPTIONAL requestor item is used to identify the requestor. The
value is only of local significance to the requestor. If the SCVP
client includes a requestor value in the request, then the SCVP
server MUST return the same value in the response.
The requestor item MUST be an octet string. No provisions are made
to ensure uniqueness of the requestor octet string; however, all of
the octets MUST have values other than zero.
4.6 responder
The OPTIONAL responder item is used to identify the server. The
value chosen is only of local significance to the SCVP server. The
responder items MUST be included if the request included a requestor
item.
Malpani, Housley, & Freeman [Page23]
INTERNET DRAFT SCVP June 2003
The responder item MUST be an octet string. No provisions are made
to ensure uniqueness of the requestor octet string; however, all of
the octets MUST have values other than zero.
4.7 replyObjects
The replyObjects item returns requested objects to the SCVP client,
each of which tells the client about a single certificate from the
request. The replyObjects item MUST be present in the response,
unless the response is reporting an error. The CertReply item MUST
contain cert, replyStatus, replyValTime, replyChecks, replyWantBack,
and valPolicy items; and the CertReply item MAY contain the
nextUpdate and certReplyExtensions optional items.
A non-error response MUST contain one CertReply for each Query item
in the request. The order is important. The first CertReply in the
sequence MUST correspond to the first Query item in the request; the
second CertReply in the sequence MUST correspond to the second Query
item in the request; and so on.
The checks item in the request determines the content of the
replyChecks item in the response. The wantBack item in the request
determines the content of the replyWantBacks item in the response.
The queryExtensions items in the request controls the absence or the
presence and content of the certReplyExtensions item in the response.
The replyObjects item uses the ReplyObjects type, which has the
following syntax:
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert CertReference,
replyStatus ReplyStatus,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
valPolicy ValidationPolicy,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }
4.7.1 cert
The cert item contains either the public key certificate or the
attribute certificate or a reference to the certificate about which
the client is requesting information.
The ASN.1 definition of Certificate is imported from [PKIX-1]; and
the definition of AttributeCertificate is imported from [PKIX-AC].
Malpani, Housley, & Freeman [Page24]
INTERNET DRAFT SCVP June 2003
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),
unrecognizedCheck (1),
unrecognizedWantBack (2),
malformedPKC (3),
malformedAC (4),
unrecognizedCertPolicy (5),
unrecognizedValPolicy (6),
unrecognizedExtension (7),
unavailableValidityTime (8),
referenceCertHashFail (9),
certPathConstructFail (10),
certPathNotValid (11),
certPathNotValidNow (12) }
The meaning of the various ReplyStatus values are:
0 Success: a definitive answer follows
1 Failure: an OID in the check item is not recognized
2 Failure: an OID in the wantBack item is not recognized
3 Failure: the public key certificate was malformed
4 Failure: the attribute certificate was malformed
5 Failure: the certificate policy OID is not recognized
6 Failure: the validation policy OID is not recognized
7 Failure: the extension OID is not recognized
8 Failure: historical data for the requested validity time is
not available
9 Failure: the referenced certificate did not match the hash
value provided
10 Failure: no certification path could be constructed
11 Failure: the constructed certification path is invalid
12 Failure: the constructed certification path is invalid, but a
query at a later time may be successful
Codes 3 and 4 are used to tell the client that the request was
properly formed, but the certificate in question was not. This is
especially useful to clients that do not parse certificates.
Malpani, Housley, & Freeman [Page25]
INTERNET DRAFT SCVP June 2003
4.7.3 replyValTime
The replyValTime item tells the time at which the information in the
CertReply was correct. The replyValTime item represents the date
and time in UTC, using GeneralizedTime type. The encoding rules for
GeneralizedTime in section 4.2 MUST be used.
Within the request, the optional validityTime item tells the date
and time relative to which the SCVP client wants the server to
perform the checks. If the validityTime is not present, the server
MUST respond as if the client provided the date and time at which
the server processes the request.
The information in the CertReply item MUST be formatted as if the
server created this portion of response at the time indicated in the
validityTime item of the query. However, if the server does not
have appropriate historical information, the server MAY either
return an error or return information for a later time.
4.7.4 replyChecks
The replyChecks contains the responses to the checks item in the
query. The replyChecks item repeats the object identifier (OID)
from the query and an integer. The value of the integer indicates
whether the requested check was successful. The OIDs in the checks
item of the query are used to identify the corresponding replyChecks
values. The OIDs in the replyChecks item MUST match the OIDs in the
checks item in the request.
The replyChecks item uses the ReplyChecks type, which has the
following syntax:
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER }
The status value for public key certification path building to a
trusted root, { id-stc 1 }, can be one of the following:
0: Built a path
1: Could not build a path
The status value for public key certification path building to a
trusted root along with simple validation processing, { id-stc 2 },
can be one of the following:
0: Valid
1: Not valid
Malpani, Housley, & Freeman [Page26]
INTERNET DRAFT SCVP June 2003
The status value for public key certification path building to a
trusted root along with complete status checking, { id-stc 3 }, can
be one of the following:
0: Good
1: Revoked
2: Unknown
3: Unavailable
The status value for AC issuer certification path building to a
trusted root, { id-stc 4 }, can be one of the following:
0: Built a path
1: Could not build a path
The status value for AC issuer certification path building to a
trusted root along with simple validation processing, { id-stc 5 },
can be one of the following:
0: Valid
1: Not valid
The status value for AC issuer certification path building to a
trusted root along with complete status checking, { id-stc 6 }, can
be one of the following:
0: Good
1: Revoked
2: Unknown
3: Unavailable
The status value for revocation status checking of an AC as well as
AC issuer certification path building to a trusted root along with
complete status checking, { id-stc 7 }, can be one of the following:
0: Good
1: Revoked
2: Unknown
3: Unavailable
4.7.5 replyWantBack
The replyWantBack contains the responses to the wantBack item in the
request. The replyWantBack item includes the object identifier
(OID) from the wantBack item in the request and an octet string.
Within the octet string is the requested value. The OIDs in the
wantBack item in the request are used to identify the corresponding
reply value. The OIDs in the replyWantBack item MUST match the OIDs
in the wantBack item in the request.
Malpani, Housley, & Freeman [Page27]
INTERNET DRAFT SCVP June 2003
The replyWantBack item uses the ReplyWantBack type, which has the
following syntax:
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
The octet string value for the certification path used to verify the
certificate in the request, { id-swb 1 }, contains the CertBundle
type. The syntax and semantics of the CertBundle type are described
in section 3.2.7.
The octet string value for the proof of revocation status, { id-swb
2 }, contains the RevocationInfo type. The syntax and semantics of
the RevocationInfo type are described in section 3.2.9.
The octet string value for the public key certificate status, { id-
swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if
the certificate is valid, and the value will be FALSE if the
certificate is not valid.
The octet string value for the public key information, { id-swb 4 },
contains the SubjectPublicKeyInfo type. The syntax and semantics of
the SubjectPublicKeyInfo type are described in [PKIX-1].
The octet string value for the AC issuer certification path used to
verify the certificate in the request, { id-swb 5 }, contains the
CertBundle type. The syntax and semantics of the CertBundle type
are described in section 3.2.7.
The octet string value for the proof of revocation status of the AC
issuer certification path, { id-swb 6 }, contains the RevocationInfo
type. The syntax and semantics of the RevocationInfo type are
described in section 3.2.9.
The octet string value for the proof of revocation status of the
attribute certificate, { id-swb 7 }, contains the RevocationInfo
type. The syntax and semantics of the RevocationInfo type are
described in section 3.2.9.
The octet string value for the attribute certificate status, { id-
swb 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if
the certificate is valid, and the value will be FALSE if the
certificate is not valid.
4.7.6 valPolicy
Malpani, Housley, & Freeman [Page28]
INTERNET DRAFT SCVP June 2003
The valPolicy item tells the validation policy used by the SCVP
server. Even if the query does not include a validation policy, the
server MUST indicate the validation policy that was used. The
valPolicy value MUST NOT be id-svp-defaultValPolicy.
The syntax and semantics of the valPolicy item are descried in
section 3.2.5.
4.7.7 nextUpdate
The nextUpdate item tells the time at which the server expects a
refresh of information regarding the validity of the certificate to
become available. The nextUpdate is especially interesting if the
certificate revocation status information is not available or the
certificate is suspended. The nextUpdate item represents the date
and time in UTC, using the GeneralizedTime type. The encoding rules
for GeneralizedTime in section 4.2 MUST be used.
4.7.8 certReplyExtensions
The certReplyExtensions contains the responses to the queryExtension
item in the request. The singleReplyExtensions item uses the
Extensions type defined in [PKIX-1]. The object identifiers (OIDs)
in the queryExtension item in the request are used to identify the
corresponding reply value. The certReplyExtensions item, when
present, contains a sequence of Extension items, each of which
contains an extnID item, a critical item, and an extnValue item.
The extnID item is an identifier for the extension. It contains the
OID that names the extension, and it MUST match one of the OIDs in
the queryExtension item in the request.
The critical item is a BOOLEAN, and it MUST be set to FALSE.
The extnValue item contains an OCTET STRING. Within the OCTET
STRING is the extension value. An ASN.1 type is specified for each
extension, and identified by extnID.
4.8 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 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
Malpani, Housley, & Freeman [Page29]
INTERNET DRAFT SCVP June 2003
the client does not like the certification path retuned, it can make
a new query and pass along this context information.
Section 3.2.4 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 another one can be found).
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. However, 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 item MAY contain 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 the SCVP. The syntax for Extensions
is imported from [PKIX-1]. The respExtensions 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) that names the extension.
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). An SCVP client MUST reject the response if it encounters
a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized.
The extnValue item contains an OCTET STRING. Within the OCTET
STRING is the extension value. An ASN.1 type is specified for each
extension, and identified by extnID.
5 Validation Policies Request
A SCVP client uses the VPRequest item to request the list of
validation policies supported by the SCVP server. When a VPRequest
is encapsulated in a MIME body part, it MUST be carried in an
application/scvp-policies-request MIME body part.
The request consists of a VPRequest encapsulated in a ContentInfo.
The request is not signed by the client.
Malpani, Housley, & Freeman [Page30]
INTERNET DRAFT SCVP June 2003
ContentInfo {
contentType id-ct-scvp-valPolRequest,
-- (1.2.840.113549.1.9.16.1.12)
content VPRequest }
The VPRequest type has the following syntax:
VPRequest ::= SEQUENCE {
scvpVersion INTEGER }
The scvpVersion item is described in section 3.1.
6 Validation Policies Response
In response to a VPRequest, the SCVP server provides a VPResponse.
When a VPResponse 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 VPRequest encapsulated in a ContentInfo.
The response is not signed by the server.
ContentInfo {
contentType id-ct-scvp-valPolResponse,
-- (1.2.840.113549.1.9.16.1.13)
content VPResponse }
The VPResponse 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.
7 SCVP Server Relay
In some network environments, especially ones that include firewalls,
an SCVP server might not be able to obtain all of the information
that it needs to process a request. However, the server might be
configured to use the services of one or more other SCVP servers to
fulfill all requests. In such cases, the SCVP client is unaware
that the initial SCVP server is using the services of other SCVP
servers. The initial SCVP server acts as a client to another SCVP
server. Unlike the original client, the SCVP server is expected to
have moderate computing and memory resources. This section
describes SCVP server-to-SCVP server exchanges. This section does
Malpani, Housley, & Freeman [Page31]
INTERNET DRAFT SCVP June 2003
not impose any requirements on SCVP clients that are not also SCVP
servers. Further, this section does not impose any requirements on
SCVP servers that do not relay requests to other SCVP servers.
When one SCVP server relays a request to another server, in an
incorrectly configured system of servers, it is possible that the
same request will be relayed back again. Any SCVP server that
relays requests MUST implement the conventions described in this
section to detect and break loops.
When an SCVP server relays a request, the request MUST include the
requestor item. If the request to be relayed already contains a
requestor item, then server-generated request MUST contain a
requestor item constructed from this value followed by a zero octet
followed by the identifier of the SCVP server. If the request to be
relayed does not contain a requestor item, then server-generated
request MUST contain only identifier of the SCVP server.
When an SVCP server receives a request that contains a requestor
item, the server MUST check for its own identifier. The identifier
could be located at the beginning of the octet string followed by a
zero octet, or it could be located between two zero octets. If the
server discovers its own identifier in the requestor item, it MUST
respond with an error, setting the responseStatus to 40.
8 SCVP ASN.1 Module
This section defines the syntax for SCVP request-response pairs.
The semantics for the messages are defined in sections 3, 4, 5, and
6. The SCVP ASN.1 module follows.
SCVP
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) 21 }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
AlgorithmIdentifier, Certificate, Extensions, Name,
SubjectPublicKeyInfo
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 18 }
AttributeCertificate
FROM PKIXAttributeCertificate -- RFC 3281
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 12 }
Malpani, Housley, & Freeman [Page32]
INTERNET DRAFT SCVP June 2003
ESSCertID FROM ExtendedSecurityServices -- RFC 2634
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) 2 } ;
-- SCVP Certificate Validation Request
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) 1 }
id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }
CVRequest ::= SEQUENCE {
scvpVersion INTEGER,
query Query,
requestor [0] OCTET STRING OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
reqExtensions [2] Extensions OPTIONAL }
Query ::= SEQUENCE {
queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference,
checks CertChecks,
wantBack WantBack,
serverContextInfo [0] OCTET STRING OPTIONAL,
valPolicy [1] ValidationPolicy OPTIONAL,
validityTime [2] GeneralizedTime OPTIONAL,
trustAnchors [3] TrustAnchors OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
queryExtensions [6] Extensions OPTIONAL }
CertReference::= CHOICE {
pkc PKCReference,
ac ACReference }
PKCReference ::= CHOICE {
cert [1] Certificate,
pkcRef [2] ESSCertID }
ACReference ::= CHOICE {
attrCert [3] AttributeCertificate,
acRef [4] ESSCertID }
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
ValidationPolicy ::= SEQUENCE {
valPolicyId OBJECT IDENTIFIER,
Malpani, Housley, & Freeman [Page33]
INTERNET DRAFT SCVP June 2003
parameters ANY DEFINED BY valPolicyId OPTIONAL }
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor
TrustAnchor ::= SEQUENCE {
anchor PKCReference,
certPolicies [1] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL }
-- if absent, use any-policy
CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
retype OBJECT IDENTIFIER,
revalue ANY DEFINED BY retype }
-- SCVP Certificate Validation Request
id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }
CVResponse ::= 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 }
ResponseStatus ::= SEQUENCE {
statusCode SCVPStatusCode,
errorMessage [0] UTF8String OPTIONAL }
SCVPStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
Malpani, Housley, & Freeman [Page34]
INTERNET DRAFT SCVP June 2003
unrecognizedSigKey (23),
badSignature (24),
unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignature (29),
invalidSignature (30),
relayingLoop (40) }
RequestReference ::= CHOICE {
requestHash [1] HashValue, -- hash of CVRequest
fullRequest [2] CVRequest }
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert ReplyCertificate,
replyStatus ReplyStatus,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
valPolicy ValidationPolicy,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }
ReplyCertificate ::= CHOICE {
pkc [1] Certificate,
ac [2] AttributeCertificate }
ReplyStatus ::= ENUMERATED {
success (0),
unrecognizedCheck (1),
unrecognizedWantBack (2),
malformedPKC (3),
malformedAC (4),
unrecognizedCertPolicy (5),
unrecognizedValPolicy (6),
unrecognizedExtension (7),
unavailableValidityTime (8),
referenceCertHashFail (9),
certPathConstructFail (10),
Malpani, Housley, & Freeman [Page35]
INTERNET DRAFT SCVP June 2003
certPathNotValid (11),
certPathNotValidNow (12) }
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER }
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
-- SCVP Validation Policies Request
id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 }
VPRequest ::= SEQUENCE {
scvpVersion INTEGER }
-- SCVP Validation Policies Response
id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }
ValPoliciesResponse ::= SEQUENCE {
scvpVersion INTEGER,
valPolicies SEQUENCE OF OBJECT IDENTIFIER }
-- SCVP Check Identifiers
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 }
-- SCVP WantBack Identifiers
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
Malpani, Housley, & Freeman [Page36]
INTERNET DRAFT SCVP June 2003
id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 }
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-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 }
-- SCVP Validation Policy Identifiers
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 }
END
9 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 requestRef item 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
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 response matches the
value in the request, an attacker can replay previous responses from
the SCVP server.
If the server does not require some sort of authorization (such as
signed requests), an attacker can get the server to respond to
arbitrary requests. Such responses may give the attacker
information about weaknesses in the server or about the timeliness
Malpani, Housley, & Freeman [Page37]
INTERNET DRAFT SCVP June 2003
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 a
different set of validation policies than it actually does. This
could result in the client requesting validation based on a policy
the server does not support or lead the client using a less
desirable policy.
SCVP does not include any confidentiality mechanisms. If
confidentiality is needed, it can be achieved with a lower-layer
security protocol.
10 References
Normative and informative references are provided.
10.1 Normative References
[STDWORDS] 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-1] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281,
April 2002.
[PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Malpani, Housley, & Freeman [Page38]
INTERNET DRAFT SCVP June 2003
List (CRL) Profile", RFC 3279, 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.
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
10.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",
RFC 3379, September 2002.
11 Acknowledgments
The lively debate in the PKIX Working Group has made a significant
impact on this protocol. Denis Pinkas and Phillip Hallam-Baker
suggested additional requirements for the protocol. 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, Peter Sylvester, and Yuriy Dzambasow provided good input,
greatly improving 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
Malpani, Housley, & Freeman [Page39]
INTERNET DRAFT SCVP June 2003
Encoding considerations: binary
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@malpani.biz>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@malpani.biz>
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: Unless reporting an error, the response is
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 servers
Malpani, Housley, & Freeman [Page40]
INTERNET DRAFT SCVP June 2003
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@malpani.biz>
Intended usage: COMMON
Author/Change controller: Ambarish Malpani <ambarish@malpani.biz>
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@malpani.biz>
Intended usage: COMMON
Author/Change controller: Ambarish Malpani <ambarish@malpani.biz>
Malpani, Housley, & Freeman [Page41]
INTERNET DRAFT SCVP June 2003
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@malpani.biz>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@malpani.biz>
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
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.
Malpani, Housley, & Freeman [Page42]
INTERNET DRAFT SCVP June 2003
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 CVRequest. 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
CVResponse.
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
Malpani Consulting Services
ambarish@malpani.biz
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
housley@Vigilsec.com
Trevor Freeman
Microsoft Corporation,
One Microsoft way.
Redmond, WA 98052
USA.
trevorf@microsoft.com
Malpani, Housley, & Freeman [Page43]
INTERNET DRAFT SCVP June 2003
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 [Page44]
| PAFTECH AB 2003-2026 | 2026-04-23 00:33:05 |