[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 5055

Internet Draft                                              T. Freeman
draft-ietf-pkix-scvp-16.txt                             Microsoft Corp
October 2004                                                R. Housley
Expires in six months                                   Vigil Security
                                                            A. Malpani
                                           Malpani Consulting Services

           Simple Certificate Validation Protocol (SCVP)


Status of this Memo

  By submitting this Internet-Draft, I certify that any applicable
  patent or other IPR claims of which I am aware have been disclosed,
  or will be disclosed, and any of which I become aware will be
  disclosed, in accordance with RFC 3668.

  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 a "work in
  progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

  IPR Statement

  By submitting this Internet-Draft, I certify that any applicable
  patent or other IPR claims of which I am aware have been disclosed,
  or will be disclosed, and any of which I become aware will be
  disclosed, in accordance with RFC 3668.

Copyright Notice

  Copyright (C) The Internet Society (2003). 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                      October 2004

Table of Contents

1 Introduction....................................................5
 1.1 SCVP overview and requirements...............................5
 1.2 Terminology..................................................6
 1.3 Validation Policies..........................................6
 1.4 Validation Algorithm.........................................7
2 Protocol Overview...............................................8
3 Validation Request..............................................9
 3.1 cvRequestVersion............................................11
   3.1.1 queriedCerts............................................12
   3.1.2 checks..................................................13
   3.1.3 wantBack................................................14
   3.1.4 validationPolicy........................................15
     3.1.4.1 validationPolRef....................................16
   3.1.5 validationAlg...........................................17
     3.1.5.1 Default Validation Algorithm........................17
     3.1.5.2 validationAlg.......................................18
     3.1.5.2.1 Basic Validation Algorithm........................18
      3.1.5.2.2 Basic Validation Algorithm Errors................19
      3.1.5.2.3 Name Validation Algorithm........................20
      3.1.5.2.4 Name Validation Algorithm Errors.................21
     3.1.5.3 userPolicySet.......................................22
     3.1.5.4 inhibitPolicyMapping................................22
     3.1.5.5 requireExplicitPolicy...............................22
     3.1.5.6 inhibitAnyPolicy....................................23
     3.1.5.7 isCA................................................23
     3.1.5.8 trustAnchors........................................23
     3.1.5.9 keyUsages...........................................24
     3.1.5.10 extendedKeyUsages..................................25
   3.1.6 responseFlags...........................................25
     3.1.6.1 responseRefHash.....................................25
     3.1.6.2 responseValidationPolByRef..........................26
     3.1.6.3 signResponse........................................26
   3.1.7 serverContextInfo.......................................26
   3.1.8 valididationTime........................................27
   3.1.9 intermediateCerts.......................................28
   3.1.10 revInfos...............................................28
   3.1.11 producedAt.............................................29
   3.1.12 queryExtensions........................................29
     3.1.12.1 extnID.............................................29
     3.1.12.2 critical...........................................29
     3.1.12.3 extnValue..........................................30
 3.2 requestorRef................................................30
 3.3 requestNonce................................................30
 3.4 requestExtensions...........................................31
   3.4.1 extnID..................................................31
   3.4.2 critical................................................31
   3.4.3 extnValue...............................................31
 3.5 dhPublicKey.................................................32
 3.6 SCVP Request Authentication.................................32
4 Validation Response............................................32

Freeman, Housley, & Malpani                                    [Page 2]


INTERNET DRAFT                   SCVP                      October 2004

 4.1 cvResponseVersion...........................................36
 4.2 policyID....................................................36
 4.3 producedAt..................................................36
 4.4 responseStatus..............................................36
 4.5 respValidationPolicy........................................38
   4.5.1 validationPolRef........................................39
   4.5.2 validationPolValues.....................................39
     4.5.2.1 validationAlg.......................................40
     4.5.2.2 inhibitPolMap.......................................40
     4.5.2.3 requireExplicitPol..................................40
     4.5.2.4 inhibitAnyPol.......................................40
     4.5.2.5 isCA................................................40
     4.5.2.6 trustAnchors........................................40
     4.5.2.7 keyUsage............................................40
     4.5.2.8 extendedKeyUsage....................................40
     4.5.2.9 validationPolicyAttr................................40
   4.5.3 userFinalPolicySet......................................40
   4.5.4 permittedSubtrees.......................................40
   4.5.5 excludedSubtrees........................................41
   4.5.6 validationPolicyAtt.....................................41
 4.6 requestRef..................................................41
   4.6.1 requestHash.............................................42
   4.6.2 fullRequest.............................................42
 4.7 requestorRef................................................42
 4.8 requestorName...............................................42
 4.9 responder...................................................43
 4.10 replyObjects...............................................43
   4.10.1 cert...................................................44
   4.10.2 replyStatus............................................44
   4.10.3 replyValTime...........................................45
   4.10.4 replyChecks............................................45
   4.10.5 replyWantBack..........................................47
   4.10.6 validationAlg..........................................48
   4.10.7 validationErrors.......................................48
   4.10.8 nextUpdate.............................................48
   4.10.9 certReplyExtensions....................................48
 4.11 responseNonce..............................................49
 4.12 serverContextInfo..........................................49
 4.13 respExtensions.............................................50
 4.14 SCVP Response Validation...................................50
   4.14.1 Simple Key Validation..................................50
   4.14.2 SCVP Server Certificate Validation.....................51
5 Server Policy Request..........................................51
 5.1 vpRequestVersion............................................51
 5.2 requestNonce................................................51
6 Validation Policy Response.....................................52
 6.1 vpResponseVersion...........................................53
 6.2 maxCVRequestVersion.........................................53
 6.3 maxVPRequestVersion.........................................53
 6.4 defaultPolicyID.............................................53
 6.5 thisUpdate..................................................53
Freeman, Housley, & Malpani                                    [Page 3]


INTERNET DRAFT                   SCVP                      October 2004

 6.6 nextUpdate..................................................53
 6.7 trustAnchors................................................54
 6.8 validationPolicies..........................................54
 6.9 validationAlgs..............................................54
 6.10 authPolicies...............................................54
 6.11 responseTypes..............................................55
 6.12 dhPublicKeyInfo............................................55
 6.13 clockSkew..................................................55
 6.14 defaultValPolicy...........................................55
7 SCVP Server Relay..............................................56
8 SCVP ASN.1 Module..............................................56
9 Security Considerations........................................64
10 References....................................................65
 10.1 Normative References.......................................65
 10.2 Informative References.....................................67
11 Acknowledgments...............................................67
Appendix A -- MIME Registrations.................................67
 A.1 application/cv-request......................................67
 A.2 application/cv-response.....................................68
 A.3 application/vp-request......................................69
 A.4 application/vp-response.....................................70
Appendix B -- SCVP over HTTP.....................................70
 B.1 SCVP Request................................................70
 B.2 SCVP Response...............................................71
 B.3 SCVP Policy Request.........................................71
 B.4 SCVP Policy Response........................................72
Appendix C -- Author Contact Information.........................72
Full Copyright Statement.........................................73

Freeman, Housley, & Malpani                                    [Page 4]


INTERNET DRAFT                   SCVP                      October 2004


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 completely
  delegates certification path construction and validation to the
  SCVP server.  This class of application is often referred to as
  delegated path validation (DPV).

  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
  only delegates certification path construction to the SCVP server.
  This class of application is often referred to as delegated path
  discovery (DPD).

1.1 SCVP overview and requirements

  The SCVP meets the mandatory 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 that uses these
Freeman, Housley, & Malpani                                    [Page 5]


INTERNET DRAFT                   SCVP                      October 2004

  services, the client inherently trusts the SCVP server as much as
  it would its own certification path validation software (if it
  contained such software).  There are two main reasons that a client
  may want to trust such an SCVP server:

     1.  The client does not want to incur the overhead of including
     certification path validation software and running it for each
     certificate it receives.

     2.  The client is in an organization or community that wants to
     centralize its PKI policies.  These policies might dictate that
     particular trust anchors are to be used and the types of policy
     checking that is to be 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 (as defined in RFC 3379 [RQMTS]) specifies the
  rules and parameters to be used by the SCVP server when validating
  a certificate.  In SCVP, a validation policy can be either mutually
  agreed between client and server, and subsequently referenced in
  request, or explicitly expressed in the request by passing all of
  the necessary parameters.

  Policy definitions can be quite long and complex, and some policies
  may allow for the setting of a few parameters such as a set of
  trust anchors.  The request can therefore be simplified if these
  previously agreed policy dependent parameters are referenced in the
  request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
  The referenced value indicates either a partial or full set of
  parameters. The client can therefore omit these agreed parameters
  from the request, only passing any parameters which are not
  specified by the previously agreed policy.  Therefore in the
  simplest form, with validation polices which define every parameter
  necessary, a SCVP request need only contain the certificate to be
  validated, the validation policy and any run-time parameters for
  the request.

  SCVP server also publishes its default validation policy settings.
  The default policy can be requested for validation and the client
  can override any default value in the request if required.  The
  default values are also used when processing requests which
  reference a validation policy other than the default one that does
  not contain the full set of parameters necessary for validation and
  the client has also omitted the missing values in the request.
Freeman, Housley, & Malpani                                    [Page 6]


INTERNET DRAFT                   SCVP                      October 2004

  Therefore a client can also simplify the request by omitting a
  parameter from a request if the default value published by the
  server is acceptable.

  The inputs to the basic certification path processing algorithm
  used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise:

    Certificate to be validated (by value or by reference)

    Validation time

    Set of Trust Anchors (by value or by reference)

    The initial policy set

    Initial policy mapping setting

    Initial any-Policy setting

    Initial explicit policy setting

  The basic certificate path processing algorithm also supports the
  following parameters which are defined in [PKIX-1] section 4

  The basic certification path processing algorithm also supports the
  following parameters which are defined in [PKIX-1] section 4:

     The usage of the key contained in the certificate (e.g., key
     encipherment, key agreement, signature)

     Other application-specific purposes for which the certified
     public key may be used.

1.4 Validation Algorithm

  The validation algorithm is determined by agreement between the
  client and the server and is represented as an OID.  The algorithm
  defines the checking that will be performed by the server to
  determine whether the certificate is valid, and it specifies any
  parameters defined in the policy.  A validation algorithm is
  therefore one of the parameters to a validation policy.  SCVP
  defines a basic validation algorithm which implements the
  certification path validation algorithm as defined in [PKIX-1].
  New validation algorithms can be specified that define additional
  parameters if needed.

  Application-specific validation algorithms in addition to those
  defined in this document can be defined to meet specific
  requirements not covered by the basic validation algorithm.  The
  validation algorithms documented here should serve as guide for the
  development of further application-specific validation algorithms.
Freeman, Housley, & Malpani                                    [Page 7]


INTERNET DRAFT                   SCVP                      October 2004

  For example, a new application-specific validation algorithm might
  require the presence of a particular name form in the subject
  alternative name extension of the certificate.

  For a certification path to be considered valid under a particular
  validation policy, it MUST be a valid certification path as defined
  in [PKIX-1] and all validation policy constraints that apply to the
  certification path MUST be verified.

  Revocation checking is one aspect of certification path validation
  defined in [PKIX-1].  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;

     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 [HTTP],
  but it can also be used with email or any other protocol that can
  transport digitally signed objects.  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 and default parameters supported by a specific SCVP server.

  Section 3 defines the certificate validation request.

  Section 4 defines the corresponding certificate validation response.

  Section 5 defines the validation policies request.

  Section 6 defines the corresponding validation policies response.

Freeman, Housley, & Malpani                                    [Page 8]


INTERNET DRAFT                   SCVP                      October 2004

  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 CVRequest item.
  When a CVRequest is encapsulated in a MIME body part,
  application/cv-request MUST be used.

  There are two forms of SCVP request: unsigned and signed.  A signed
  request is used to authenticate the client to the server or to
  provide an anonymous client integrity over the request-response
  pair.  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 CVRequest encapsulated in a CMS
  ContentInfo [CMS].  An overview of these structures are provided
  below and are only intended as illustrative.  The definitive ASN.1
  is found in [CMS].  Many details are not shown, but the way that
  SCVP makes use of CMS is clearly illustrated.

    ContentInfo {
      contentType        id-ct-scvp-certValRequest,
                                   -- (1.2.840.113549.1.9.16.1.10)
      content            CVRequest }

  The signed request consists of a CVRequest encapsulated in either a
  SignedData or AuthenticatedData which is in turn encapsulated in a
  ContentInfo.   An overview of these structures are 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       [0] IMPLICIT CertificateSet Optional,
      crls               [1] IMPLICIT CertificateRevocationLists
                                   Optional,
      signerInfos        SET OF SignerInfo } -- only one in SCVP

    SignerInfo {
      version            CMSVersion,
      sid                SignerIdentifier,
Freeman, Housley, & Malpani                                    [Page 9]


INTERNET DRAFT                   SCVP                      October 2004

      digestAlgorithm    DigestAlgorithmIdentifier,
      signedAttrs        SignedAttributes, -- Required
      signatureAlgorithm SignatureAlgorithmIdentifier,
      signature          SignatureValue,
      unsignedAttrs      UnsignedAttributes } -- not used in SCVP

    EncapsulatedContentInfo {
      eContentType       id-ct-scvp-certValRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
      eContent           OCTET STRING } -- Contains CVRequest

  AuthenticatedData example:

    ContentInfo {
      contentType       id-ct-authData,
                                   -- (1.2.840.113549.1.9.16.1.2)
      content           AuthenticatedData }

    AuthenticatedData {
      version           CMSVersion,
      originatorInfo    OriginatorInfo, -- Optional
      recipientInfos    RecipientInfos, -- Only SCVP server
      macAlgorithm      MessageAuthenticationCodeAlgorithm,
      digestAlgorithm   DigestAlgorithmIdentifier, -- Optional
      encapContentInfo  EncapsulatedContentInfo,
      authAttrs         AuthAttributes, -- Required
      mac               MessageAuthenticationCode,
      unauthAttrs       UnauthAttributes } -- not used in SCVP

    EncapsulatedContentInfo {
      eContentType       id-ct-scvp-certValRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
      eContent           OCTET STRING } -- Contains CVRequest

  All SCVP clients MUST support SignedData for signed requests and
  responses.  An SCVP client SHOULD support authenticatedData for
  signed requests and responses.

  If the client uses signedData it MUST have a public key that has
  been bound to a subject identity by a certificate that conforms to
  the PKIX profile [PKIX-1] and that certificate MUST be suitable for
  signing the SCVP request.  That is:

     If the key usage extension is present, either the digital
     signature or the non-repudiation bit MUST be asserted.

     If the extended key usage extension is present, it MUST contain
     either the client authentication OID, the SCVP client OID, or
     some other OID by agreement with the SCVP server.

Freeman, Housley, & Malpani                                    [Page 10]


INTERNET DRAFT                   SCVP                      October 2004

  The client MUST put an unambiguous reference to its certificate in
  the SignedData or AuthenticatedData request. The client SHOULD
  include the signers certificate in the request, but MAY omit the
  certificate to reduce the size of the request.  The client MAY
  include other certificates in the request to aid the validation of
  the signers certificates by the SCVP server.

  The syntax and semantics for SignedData, AuthenticatedData, and
  ContentInfo are defined in [CMS].  The syntax and semantics for
  CVRequest are defined below.  The CVRequest item contains the
  client request.  The CVRequest contains the cvRequestVersion and
  query items; and the CVRequest MAY also contain the requestorRef,
  requestNonce, and requestExtensions items.

  The CVRequest MUST have the following syntax:

    CVRequest ::= SEQUENCE {
      cvRequestVersion        INTEGER,
      query                   Query,
      requestorRef        [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                OPTIONAL,
      requestNonce        [1] OCTET STRING OPTIONAL,
      requestExtensions   [2] Extensions OPTIONAL
      dhPublicKey         [3] DHPublicKey OPTIONAL}

  Each of the items within the CVRequest is described in the
  following sections.

3.1 cvRequestVersion

  The cvRequestVersion item defines the version of the SCVP CVRequest
  used in a request.  The subsequent response MUST use the same
  version number.  The value of the cvRequestVersion item MUST be one
  (1) for a client implementing this specification.  Future updates
  to this specification must specify other values if there are any
  changes to syntax or semantics.

  query item 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 queriedCerts items as well
  as one checks, one wantBack and one validationPolicy item; and a
  query MAY also contain responseRefHash, responseValidationPolByRef,
  signResponse, serverContextInfo, validationTime, intermediateCerts,
  revInfos, producedAt, and queryExtensions items.

  Query MUST have the following syntax:

  Query ::= SEQUENCE {
   queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference,
   checks                     CertChecks,
Freeman, Housley, & Malpani                                    [Page 11]


INTERNET DRAFT                   SCVP                      October 2004

   wantBack                   WantBack,
   validationPolicy           ValidationPolicy,
   responseFlags              ResponseFlags OPTIONAL,
   serverContextInfo      [0] OCTET STRING OPTIONAL,
   validationTime         [1] GeneralizedTime OPTIONAL,
   intermediateCerts      [2] CertBundle OPTIONAL,
   revInfos               [3] RevocationInfos OPTIONAL,
   producedAt             [4] GeneralizedTime OPTIONAL,
   queryExtensions        [5] Extensions OPTIONAL }

  The list of certificate references in the query item tells the
  server the certificate(s) for which the client wants information.
  The checks item specifies the checking that the client wants
  performed.  The wantBack item specifies the objects that the client
  wants the server to return in the response.  The validationPolicy
  item specifies the validation policy that the client wants the
  server to employ.  The requestRefHash, responseValidationPolByRef
  and signResponse items allow the client to request optional
  features for the response.  The serverContextInfo item tells the
  server that additional information from a previous request-response
  is desired.  The validationTime item tells the date and time
  relative to which the client wants the server to perform the checks.
  The intermediateCerts and revInfos items provide context for the
  client request.  The queryExtensions item provides for future
  expansion of the query syntax.  The syntax and semantics of each of
  these items is discussed in the following sections.

3.1.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 [SHA-1] 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              [0] Certificate,
      pkcRef            [1] ESSCertID }

    ACReference ::= CHOICE {
      attrCert          [2] AttributeCertificate,
      acRef             [3] ESSCertID }

Freeman, Housley, & Malpani                                    [Page 12]


INTERNET DRAFT                   SCVP                      October 2004

  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.1.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 (OIDs).  Each OID tells the SCVP server what
  checking the client expects the server to perform.  For each check
  specified in the request, the SCVP server MUST perform all of the
  requested checks, or return an error.

  Revocation status checking inherently includes certification path
  construction.  Also, building a validated certification path does
  not imply revocation status checks.  A server may still choose to
  perform revocation status checks when performing path construction,
  although this information cannot be returned to the client.

  The checks item uses the CertChecks type, which has the following
  syntax:

    CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

  A list of 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 trust anchor;

    - Build a validated certification path to a trust anchor; 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 trust anchor for the AC
       issuer;

    - Build a validated certification path to a trust anchor for the
       AC issuer;

    - Do revocation status checks on the certification path for the
       AC issuer; and

Freeman, Housley, & Malpani                                    [Page 13]


INTERNET DRAFT                   SCVP                      October 2004

    - 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-valid-pkc-path   OBJECT IDENTIFIER ::= { id-stc 1 }
  id-stc-build-status-checked-pkc-path
                                OBJECT IDENTIFIER ::= { id-stc 2 }
  id-stc-build-valid-aa-path    OBJECT IDENTIFIER ::= { id-stc 4 }
  id-stc-build-status-checked-aa-path
                                OBJECT IDENTIFIER ::= { id-stc 5 }

3.1.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 (OIDs).  Each OID tells the SCVP server what the
  client wants to know about the queriedCerts item.  For each type of
  information specified in the request, the server MUST return
  information regarding its finding (in a successful response).

  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:

    - The certificate that was validated;
Freeman, Housley, & Malpani                                    [Page 14]


INTERNET DRAFT                   SCVP                      October 2004


    - The certification path built for the certificate including the
       certificate that was validated;

    - Proof of revocation status for each certificate in the
       certification path;

    - Status indication; and

    - The public key from the certificate.

  For attribute certificates, the types of information that can be
  requested are:

    - The attribute certificate that was validated;

    - The 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.

  The client can also request a non-cached response to the request by
  including wantback id-swb-non-cached-resp in the request.

  For these purposes, the following OIDs are defined:

    id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }

   id-swb-pkc-best-cert-path       OBJECT IDENTIFIER ::= { id-swb 1 }
   id-swb-pkc-revocation-info      OBJECT IDENTIFIER ::= { id-swb 2 }
   id-swb-pkc-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 }
   id-swb-non-cached-resp          OBJECT IDENTIFIER ::= { id-swb 9 }
   id-swb-pkc-cert                 OBJECT IDENTIFIER ::= { id-swb 10}
   id-swb-ac-cert                  OBJECT IDENTIFIER ::= { id-swb 11}
   id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}

3.1.4 validationPolicy

  The validationPolicy item, defines the validation policy The
  validationPolicy item defines the validation policy that the client
  wants the SCVP server to use during certificate validation.  If
Freeman, Housley, & Malpani                                    [Page 15]


INTERNET DRAFT                   SCVP                      October 2004

  this policy cannot be used for any reason, then the server MUST
  return an error response.

  The client and server can optionally agree on a set of parameters
  which may fully or partially define a validation policy.  If the
  policy defines all parameters necessary for processing an SCVP
  request, then the client need only supply a reference to the policy
  in this item.  If a partial set of parameters has been agreed upon,
  then the client supplies a reference to the policy plus whatever
  parameters are necessary to complete the request in this item.

  The syntax of the validationPolicy item is:

  ValidationPolicy ::= SEQUENCE {
    validationPolRef          ValidationPolRef,
    validationAlg         [0] ValidationAlg OPTIONAL,
    userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                IDENTIFIER OPTIONAL,
    inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
    requireExplicitPolicy [3] BOOLEAN OPTIONAL,
    inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
    isCA                  [5] BOOLEAN OPTIONAL,
    trustAnchors          [6] TrustAnchors OPTIONAL,
    keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                 OPTIONAL,
    extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}

  The validationPolRef item is required, but the remainder of the
  items are optional.  The optional items are used to provide
  validation policy parameters.  When the validation policy has no
  parameters, all of the optional items are absent.  The
  validationAlg item specifies the validation algorithm. The
  userPolicySet item provides an acceptable set of certificate
  policies.  The inhibitPolicyMapping item inhibits certificate
  policy mapping during certification path validation.  The
  requireExplicitPolicy item requires at least one valid certificate
  policy in the certificate policies extension.  The inhibitAnyPolicy
  item indicates whether the any-policy certificate policy OID is
  processed or ignored when evaluating certificate policy.  The isCA
  item indicates whether the client expects the certificate subject
  to be a CA.  The trustAnchors item indicates the trust anchors that
  are acceptable to the client.  The keyUsages item indicates the
  technical usage of the public key that is to be confirmed by the
  server as acceptable.  The extendedKeyUsages item indicates the
  application-specific usage of the public key that is to be
  confirmed by the server as acceptable.  The syntax and semantics of
  each of these items is discussed in the following sections.

3.1.4.1 validationPolRef

Freeman, Housley, & Malpani                                    [Page 16]


INTERNET DRAFT                   SCVP                      October 2004

  The reference to the validation policy can be either an OID or a
  URI.  In either case, the client and server have agreed that the
  value represents a particular validation policy.  The URI can point
  to a human readable definition of the policy to facilitate correct
  configuration.

    - serverContextInfo; and

    - the client's signature on the request.

  The syntax of the ValidationPolRef item is:

  ValidationPolRef::= CHOICE {
    valPolRefByOID         [0] OBJECT IDENTIFIER,
    valPolRefByURI         [1] IA5String}


  SCVP servers SHOULD support serverContextInfo.  SCVP clients MAY
  support serverContextInfo

3.1.5 validationAlg

  The validationAlg item, defines the validation algorithm to be used
  by the SCVP server during certificate validation.  The value of
  this item can be determined by agreement between the client and the
  server, and is represented as an object identifier.  The server
  might want to assign additional object identifiers that indicate
  that some settings are used in addition to others given in the
  request.  In this way, the validation algorithm object identifier
  can be a shorthand for some SCVP options, but not others.

  The validationAlg item uses the ValidationAlg type, which has the
  following syntax:

    ValidationAlg ::= SEQUENCE {
      valAlgId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valAlgId OPTIONAL }

3.1.5.1 Default Validation Algorithm

  The client can request the SCVP server's default validation policy
  or another validation 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 }

  The default validation policy MUST use the basic validation
  algorithm (see section 3.1.5.2.1).
Freeman, Housley, & Malpani                                    [Page 17]


INTERNET DRAFT                   SCVP                      October 2004


  When using the default validation policy, the client can override
  any of the default parameter values by supplying a specific value
  in the request.  The SCVP server MUST make use of the provided
  parameter values or return an error response.

  All SCVP servers MUST support the default policy, but local policy
  MAY require the server to send an error response to all requests
  using the default policy.

  Neither the clients nor server MUST dereference the URI during SCVP
  request processing.  The URI is simply used as a reference for the
  validation policy.  Clients and server MAY dereference the URI as
  part of configuration.

  The syntax of the validationPolRef is:

    ValidationPolRef ::= CHOICE {
      valPolRefByOID     [0] OBJECT IDENTIFIER,
      valPolRefByURI     [1] IA5String }

  If there are any conflicts between the non-default policy
  referenced in the request and any supplied parameter values in the
  request, then the server MUST return an error response.

3.1.5.2 validationAlg

  The optional validationAlg item defines the validation algorithm to
  be used by the SCVP server during certificate validation.  The
  value of this item can be determined by agreement between the
  client and the server, and the validation algorithm is represented
  by an object identifier.

   The syntax of the validationAlg is:

    ValidationAlg ::= SEQUENCE {
      valAlgId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valAlgId OPTIONAL }

  The following section specifies the basic validation algorithm and
  the name validation algorithm.  SCVP clients and servers MUST
  support both validation algorithms defined in this section.  Other
  validation algorithms can be specified in other documents for use
  with specific applications.  SCVP clients and servers MAY support
  any such validation algorithms.

3.1.5.2.1 Basic Validation Algorithm

  The client can request use of the SCVP basic validation algorithm
  or another algorithm.  The basic validation algorithm implements
  the full certification path validation algorithm as defined in
Freeman, Housley, & Malpani                                    [Page 18]


INTERNET DRAFT                   SCVP                      October 2004

  section 6 of [PKIX-1].  Other validation algorithms MAY implement
  functions over and above those in the basic algorithm, but
  validation algorithms MUST generate results compliant with the
  basic validation algorithm.  That is, none of the validation
  requirements in the basic algorithm can be omitted from any newly
  defined validation algorithms.  However, other validation
  algorithms MAY reject paths which are valid using the basic
  validation algorithm.  The object identifier to identify the basic
  validation algorithm is:

    id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }

  When id-svp-basicValAlg appears as in valAlgId, the parameters item
  MUST be absent.

  The meaning of the default validation algorithm 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 userPolicySet
       item.  If no certificate policies are specified in the
       userPolicySet 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.1.5.2.2 Basic Validation Algorithm Errors

  The following errors are defined for the basic validation
  algorithm:

  id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg

  id-bvae-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
  id-bvae-notYetValid          OBJECT IDENTIFIER ::= { id-bvae 2 }
  id-bvae-wrong-Anchor         OBJECT IDENTIFIER ::= { id-bvae 3 }
  id-bvae-partial-chain        OBJECT IDENTIFIER ::= { id-bvae 4 }
  id-bvae-invalid-Key-Usage    OBJECT IDENTIFIER ::= { id-bvae 10 }
  id-bvae-invalid-Purpose      OBJECT IDENTIFIER ::= { id-bvae 11 }
  id-bvae-invalid-Policy       OBJECT IDENTIFIER ::= { id-bvae 12 }
  id-bvae-invalid-Name         OBJECT IDENTIFIER ::= { id-bvae 13 }
  id-bvae-invalid-Entity       OBJECT IDENTIFIER ::= { id-bvae 14 }
  id-bvae-invalid-Depth        OBJECT IDENTIFIER ::= { id-bvae 15 }

  The id-bvae-expired value means that the validation time used for
  the request was later than the notAfter time in the certificate.

Freeman, Housley, & Malpani                                    [Page 19]


INTERNET DRAFT                   SCVP                      October 2004

  The id-bvae-notYetValid value means that the validation time used
  for the request was before the notBefore time in the certificate.

  The id-bvae-wrong-Anchor value means that a certification path was
  able to be constructed but that the trust anchor for the path was
  not one of the trust anchors required.

  The id-bvae-partial-chain value means that a certification path was
  unable to be constructed to any trust anchor.

  The id-bvae-invalid-Key-Usage value means that one of the
  certificates in the certification path has the wrong key
  usage(PKIX-1 section 4.2.1.3).  The key in a CA certificate can
  verify a certificate, but the key usage in the certificate does not
  contain the cert sign bit.

  The id-bvae-invalidPurpose value means that one of the certificates
  in the certification path has the wrong purpose (PKIX-1 section
  4.2.1.13).

  The id-bvae-invalidCertPolicy value means that some part of
  certificate policy evaluation has failed.  For example, the
  requested policy was not valid in the certificate or the request
  explicit policy is true and there are no valid certificate polices.

  The id-bvae-invalidName value means that one of the names in one of
  the certificates in the certification path violates a name
  constraints extension in a parent certificate.

  The id-bvae-invalidEntity value means that one of the entity types
  in the certification pathas defined in the basic constraints
  extension is invalid.  That is, an end entity has signed a
  certificate.

  The id-bvae-invalidPathDepth value means that the certification
  path length violates the path length constraints in the basic
  constraints extension.

3.1.5.2.3 Name Validation Algorithm

  The name validation algorithm allows the client to supply an
  application identifier and a name to the server.  The application
  identifier defines the name matching rules to use in comparing the
  name supplied in the request with the names in the certificate.

    id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
    id-svp-dnValAlg   OBJECT IDENTIFIER ::= { id-svp 4 }


  When the id-svp-NameValAlg appears as a valAlgId, the parameters
  MUST use the NameValidationAlgParms syntax:
Freeman, Housley, & Malpani                                    [Page 20]


INTERNET DRAFT                   SCVP                      October 2004


    NameValidationAlgParms ::= SEQUENCE {
      keyPurposeId      KeyPurposeId,
      validationNames   GeneralNames }

  KeyPurposeId and GeneralNames are defined in [PKIX-1].

  If more than one name is supplied in the validationNames value, all
  names MUST be of the same type and be valid according to the name
  matching rules associated with the KeyPurposeId.

  If the keyPurposeID supplied in the request is id-svp-dnValAlg,
  then GeneralNames supplied in the request MUST be a DN name, and
  the matching rules to be used are defined in [PKIX-1].

  If the keyPurposeID supplied in the request is id-kp-serverAuth
  [PKIX-1], then GeneralNames 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 GeneralNames supplied in the request MUST be a
  rfc822Name, and the matching rules are defined in [SMIME-CERT].

  SCVP server MUST support the name validation algorithms for id-svp-
  dnValAlg, id-kp-serverAuth, id-kp-mailProtection. SCVP server may
  suport other name validation algorithms.

3.1.5.2.4 Name Validation Algorithm Errors

  The following errors are defined for the Name Validation Algorithm

  id-nvae OBJECT IDENTIFIER ::= id-svp-NameValAlg

  id-nvae-name-mismatch    OBJECT IDENTIFIER ::= { id-nvae 1 }
  id-nvae-no-name          OBJECT IDENTIFIER ::= { id-nvae 2 }
  id-nvae-unknown-pupose   OBJECT IDENTIFIER ::= { id-nvae 3 }
  id-nvae-bad-name         OBJECT IDENTIFIER ::= { id-nvae 4 }
  id-nvae-bad-name-type    OBJECT IDENTIFIER ::= { id-nvae 5 }
  id-nvae-mixed-names      OBJECT IDENTIFIER ::= { id-nvae 6 }

  The id-nvae-nameMismatch value 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 example1.com, the certificate
  contained a DNS name of example.com.

  The id-nvae-noCertName value 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
Freeman, Housley, & Malpani                                    [Page 21]


INTERNET DRAFT                   SCVP                      October 2004

  example, the client supplied a DNS name of example1.com, the
  certificate only contained a rfc822Name of user@example.com.

  The id-nvae-unknownPupose value means the client supplied
  KeyPurposeID which the server does not recognize.

  The id-nvae-badName value means the client supplied either and
  empty or malformed name in the request.

  The id-nvae-badNameType value 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@example.com.

  The id-nvae-mixedNames value means the client supplied multiple
  names in the request of different types.

  The userPolicySet item specifies a list of policy identifiers that
  the SCVP server MUST use when forming and validating a certificate
  If certPolicies is not specified, then any-policy MUST be used.

3.1.5.3 userPolicySet

  The userPolicySet item specifies a list of certificate policy
  identifiers that the SCVP server MUST use when constructing and
  validating a certification path.  If userPolicySet is not specified,
  then any-policy MUST be used.

  SCVP clients SHOULD support userPolicySet item in requests, and
  SCVP servers MUST support userPolicySet item in requests.

3.1.5.4 inhibitPolicyMapping

  The inihibitPolicyMapping specifies an input to the certification
  path validation algorithm, and it controls whether policy mapping
  is allowed in the certification path validation (see [PKIX-1],
  section 6.1.1).  By default the server allows policy mapping as
  part of certification path validation.  If the client wants the
  server to inhibit policy mapping, inhibitPolicyMapping is set to
  TRUE in the request.

  SCVP clients and servers MUST support the default behavior.  SCVP
  clients MAY support inhibiting policy mapping.  SCVP servers SHOULD
  support inhibiting policy mapping.

3.1.5.5 requireExplicitPolicy

  The requireExplicitPolicy specifies an input to the certification
  path validation algorithm, and it controls whether there must be at
  least one valid policy in the certificate policies extension (see
  [PKIX], section 6.1.1).  By default the server accepts no policies
Freeman, Housley, & Malpani                                    [Page 22]


INTERNET DRAFT                   SCVP                      October 2004

  in the certificate policies extension of valid certificates.  If
  the client wants the server to require at least one policy,
  requireExplicitPolicy is set to TRUE in the request.

  SCVP clients and servers MUST support the default behavior.  SCVP
  clients MAY support requiring explicit policies.  SCVP server
  SHOULD support requiring explicit policies.

3.1.5.6 inhibitAnyPolicy

  The inhibitAnyPolicy specifies an input to the certification path
  validation algorithm (see [PKIX], section 6.1.1), and it controls
  whether the any-policy OID is processed or ignored when evaluating
  certificate policy.  By default the server processes the any-policy
  OID.  If the client wants the server to ignore the any-policy OID,
  inhibitAnyPolicy MUST be set to TRUE in the request.  If the value
  is absent in the request or the value is set to FALSE, the server
  MUST process the any-policy OID.

  SCVP clients and servers MUST support the default behavior.  SCVP
  clients MAY support ignoring the any-policy OID.  SCVP servers
  SHOULD support ignoring the any-policy OID.

3.1.5.7 isCA

  The isCA specifies whether the client expects the certificate
  subject to be a CA.  This corresponds to CA BOOLEAN value in the
  basic constraints extension [PKIX-1, 4.2.1.10].

  If the client requires the entity type of certificate being
  validated to be a CA, then it MUST set the value of isCA to be TRUE
  in the request.

  If the client requires the subject to be an end entity, then it
  MUST set the value to FALSE.

  If the client does not care about the entity type, then it MUST
  omit the BOOLEAN value.  If the BOOLEAN value is omitted from the
  request and the client submits a CA certificate as the subject of
  the validation request, then a server MUST NOT treat this as an
  error.

  SCVP client and server MUST support the default behavior.  SCVP
  client SHOULD support setting the BOOLEAN value to TRUE, and the
  SVCP client MAY support setting the BOOLEAN value to FALSE.  SCVP
  server MUST support the isCA BOOLEAN being set to either TRUE or
  FALSE.

3.1.5.8 trustAnchors

Freeman, Housley, & Malpani                                    [Page 23]


INTERNET DRAFT                   SCVP                      October 2004

  The trustAnchors item specifies the trust anchors at which the
  certification path must terminate in if the path is to be
  considered valid by the SCVP server for the request.  If a
  trustAnchors item is present, the server MUST NOT consider any
  certification paths ending in other trust anchors as valid.

  The TrustAnchors type contains one or more trust anchor
  specification.  A certificate reference can be used to identify the
  trust anchor by certificate hash and optionally a distinguished
  name with serial number.  Alternatively, trust anchors can be
  provided directly.  The order of trust anchor specifications within
  the sequence is not important.  Any CA certificate which meets the
  requirements of [PKIX-1] for signing certificates can be provided
  as a trust anchor.  If a trust anchor is supplied which does not
  meet these requirements, the server MUST return an error response.

  The trust anchor itself, regardless of its form, MUST NOT be
  included in any certification path returned by the SCVP server.

  TrustAnchors has the following syntax:

    TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference

  SCVP server MUST support TrustAnchors.  SCVP clients SHOULD support
  trust anchors.

3.1.5.9 keyUsages

  The key usage extension [PKIX-1, section 4.2.1.3] in the
  certificate defines the technical purpose (such as encipherment,
  signature, and certificate signing) of the key contained in the
  certificate.  If the client wishes to confirm the technical usage,
  then they can communicate the usage they want to validate by the
  same structure using the same semantics as defined in [PKIX-1].
  Therefore, if the client obtained the certificate in the context of
  a digital signature, they can confirm this use by including a
  keyUsage structure with the digital signature bit set.

  The keyUsages item can contain one or more keyUsage definitions to
  allow the client to search for a set of patterns any one of which
  is acceptable to the client.  If the client whishes to match
  against multiple possibilities that the client pass in a sequence
  of possible patterns.  Each keyUasge can contain a set of one or
  more bits set in the request, all bits MUST be present in the
  certificate to match against an instance of the keyUsage in the
  SCVP request. If the certificate key usage extension contains more
  usages than requested, then the certificate MUST be considered a
  match. Therefore if a client whishes to check for either digital
  signature or non-repudiation, then the client provides two keyUsage
  values, one with digital signature set, and the other with non-
  repudiation set. If the key usage extension is absent from the
Freeman, Housley, & Malpani                                    [Page 24]


INTERNET DRAFT                   SCVP                      October 2004

  certificate, the certificate MUST be considered good for all usages
  therefore any pattern in the SCVP request will match.

  SCVP clients SHOULD support keyUsages, and SCVP servers MUST
  support keyUsages.

3.1.5.10 extendedKeyUsages

  The extended key usage extension [PKIX-1, section 4.2.1.13] defines
  more abstract technical purposes in addition to or in place of the
  purposes indicated in the key usage extension for which the
  certified public key may be used.  If the client wishes to confirm
  the extended key usage, then they can communicate the usage they
  want to validate by the same extension using the same semantics as
  defined in [PKIX-1]. Therefore if the client obtained the
  certificate in the context of a TLS server, they can confirm this
  usage by including the extended key usage structure with the id-kp-
  serverAuth object identifier.  If more than one usage is set in the
  request, all usages MUST be present in the certificate. If the
  certificate extension contains more usages than requested, then the
  certificate MUST be considered a match.

  SCVP clients SHOULD support extendedKeyUsages, and SCVP servers
  MUST support extendedKeyUsages.

3.1.6 responseFlags

  The optional response flags item allows the client to indicate
  which optional features in the CVResponse it wants the server to
  include.  If the default values for all of the flags are used, then
  the response flags item MUST NOT be included in the request.

  The syntax of the responseFlags is:

  ResponseFlags ::= SEQUENCE {
    responseRefHash            BOOLEAN DEFAULT TRUE,
    responseValidationPolByRef BOOLEAN DEFAULT TRUE,
    signResponse               BOOLEAN DEFAULT TRUE }

  Each of the response flags is described in the following sections.

3.1.6.1 responseRefHash

  The responseRefHash controls how the server identifies the request
  to which it is responding.  By default, the server includes a hash
  of the request in the response.  If the client wants the server to
  include the full request in the response, responseRefHash is set to
  FALSE.  The main reason a client would request the server to
  include the full request in the response is to archive the request-
  response exchange in a single object.  That is, the client wants to
  archive a single object which includes both request and response.
Freeman, Housley, & Malpani                                    [Page 25]


INTERNET DRAFT                   SCVP                      October 2004


  SCVP clients and servers MUST support the default behavior.  SCVP
  clients MAY support requesting and processing the full request.
  SCVP servers SHOULD support returning the full request.

3.1.6.2 responseValidationPolByRef

  The responseValidationPolByRef controls whether the response
  includes by reference or by value the validation policy used to
  process the request.  By default the response will contain
  references to the validation policy.  If the client wants the
  validation policy to be included by value, then the
  responseValidationPolByRef is set to FALSE.  The main reason a
  client would request the server to include validation policy to be
  included by value is to archive the request-response exchange in a
  single object.  That is, the client wants to archive the CVResponse
  and have it include every aspect of the validation policy.

  SCVP clients and servers MUST support the default behavior.  SCVP
  clients MAY support requesting and processing the
  responseValidationPolByRef.  SVCP server SHOULD support returning
  the responseValidationPolByRef.

3.1.6.3 signResponse

  The signResponse indicates whether the client requires the server
  to sign the response.  If the client is performing full
  certification path validation on the response and it is not
  concerned about the source of the response, then the client does
  not benefit from a signature on the response.  In this case, the
  client can indicate to the server that a signature is unnecessary.
  However, the server is always permitted to return a signed response.

  SCVP clients that support delegated path discovery (DPD) as defined
  in [RQMTS] MUST support setting this value to FALSE.

  SCVP clients that support delegated path validation (DPV) as
  defined in [RQMTS] require a signed response.  Such clients MUST
  always set this value to TRUE or accept the default behavior, which
  requires the server to return a signed response.

  SCVP servers MUST support returning signed responses, and SCVP
  servers SHOULD support returning unsigned responses.  Based on
  local policy, the server can be configured return signed or
  unsigned responses if this value is set to FALSE.

3.1.7 serverContextInfo

  The optional serverContextInfo item, if present, contains context
  from a previous request-response exchange with the same SCVP server.
  It allows the server to return more than one certification path for
Freeman, Housley, & Malpani                                    [Page 26]


INTERNET DRAFT                   SCVP                      October 2004

  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.

  SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD
  support serverContextInfo.

3.1.8 valididationTime

  The optional validationTime item, if present, tells the date and
  time relative to which the SCVP client wants the server to perform
  the checks.  If the validationTime is not present, the server MUST
  perform the validation using the date and time at which the server
  processes the request.  If the validationTime is present, it MUST
  be encoded as GeneralizedTime.  The validationTime provided MUST be
  a retrospective time since the server can only perform a validity
  check using the current time (default) or previous time.  A Server
  can ignore the validationTime provided in the request if the time
  is within the clock skew of the servers current time.

  GeneralizedTime values MUST be expressed Universal Coordinated Time
  (UTC) (which is also known as Greenwich Mean Time and Zulu time)
  and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
  when the number of seconds is zero.  GeneralizedTime values MUST
  NOT include fractional seconds.

  The information in the corresponding CertReply item in the response
  MUST be formatted as if the server created the response at the time
  indicated in the validationTime.  However, if the server does not
  have appropriate historical information, the server MUST return an
  error response.

  SCVP servers MUST apply a clock skew to the validity time to allow
  for minor time synchronization errors.  The default value is 10
Freeman, Housley, & Malpani                                    [Page 27]


INTERNET DRAFT                   SCVP                      October 2004

  minutes.  If the server uses a value other than the default it MUST
  include the clock skew value in the validation policy response.

  SCVP clients MAY support validationTime other than the current time.
  SCVP servers MUST support using its current time, and SHOULD
  support the client setting the validationTime in the request.

3.1.9 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.  When present, the intermediateCerts item MUST contain at
  least one certificate, and the intermediateCerts item MUST be
  structured as a CertBundle.  The certificates in the
  intermediateCerts MUST NOT be considered as valid 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 Certificate

  SCVP clients SHOULD support intermediateCerts, and SCVP servers
  MUST support intermediateCerts.

3.1.10 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 this information when validating certification paths.
  The purpose of the revInfos item is to provide revocation
  information to which the server might not otherwise have access,
  such as an OCSP response that the client received along with the
  certificate.  Note that the information in the revInfos item might
  not be used by the server.  For example, the revocation information
  might be associated with certificates that the server does not use
  in the certification path that it constructs.

  Clients SHOULD be courteous to the SCVP server by separating CRLs
  and delta CRLs.  However, since the two share a common syntax, SCVP
  servers SHOULD accept delta CRLs even if they are identified as
  regular CRLs by the SCVP client.

  CRLs, delta CRLs, and OCSP responses can be provided as revocation
  information.  If needed, additional object identifiers can be
  assigned for additional revocation information types in the future.
Freeman, Housley, & Malpani                                    [Page 28]


INTERNET DRAFT                   SCVP                      October 2004


  The revInfos item uses the RevocationInfos type, which has the
  following syntax:

    RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo

  RevocationInfo ::= CHOICE {
    crl                    [0] CertificateList,
    delta-crl              [1] CertificateList,
    ocsp                   [2] OCSPResponse,
    other                  [3] OtherRevInfo }

  OtherRevInfo ::= SEQUENCE {
    riType                     OBJECT IDENTIFIER,
    riValue                    ANY DEFINED BY riType }

3.1.11 producedAt

  The client MAY allow the server to use a cached SCVP response.
  When doing so, the client uses the producedAt item to express
  requirements on the freshness of the cached response.  The
  producedAt item tells the earliest date and time at which an
  acceptable cached response could have been produced.  The
  producedAt item represents the date and time in UTC, using the
  GeneralizedTime type.  The value in the producedAt item is
  independent of the validation time.

  GeneralizedTime value MUST be expressed in UTC, as defined in
  section 3.1.8.

  SCVP client MAY support using producedAt values in the request.
  SCVP server SHOULD support the producedAt values in the request.

3.1.12 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.
  Each of these is described in the following sections.

3.1.12.1 extnID

  The extnID item is an identifier for the extension.  It contains
  the object identifier that names the extension.

3.1.12.2 critical

Freeman, Housley, & Malpani                                    [Page 29]


INTERNET DRAFT                   SCVP                      October 2004

  The critical item is a BOOLEAN.  Each extension is designated as
  either critical (with a value of TRUE) or non-critical (with a
  value of FALSE).  By default, the extension is non-critical.  An
  SCVP server MUST reject the query if it encounters a critical
  extension that it does not recognize; however, a non-critical
  extension MAY be ignored if it is not recognized.

3.1.12.3 extnValue

  The extnValue item is an octet string, which contains the extension
  value.  An ASN.1 type is specified for each extension, identified
  by the associated extnID object identifier.

3.2 requestorRef

  The optional requestorRef item is a local reference to the client,
  and it is intended for use in environments where SCVP relay is
  employed.  As described in [REQMTS],   some network environments a
  SCVP server might not be able to obtain all of the information that
  it needs to process a request.  However, the SCVP server might be
  configured to use the services of one or more other SCVP servers to
  fulfill all requests.  In such cases, the client is unaware that
  the queried SCVP server is using the services of other SCVP servers,
  and the client-queried SCVP server acts as a SCVP client to another
  SCVP server.  Unlike the original client, the SCVP server is
  expected to have moderate computing and memory resources, enabling
  the use of relay, re-direct or multicasting mechanisms.  The
  requestorRef item is needed by SCVP servers that act as client to
  other SCVP servers in order to match a response to the original
  request which triggered it.  The requestorRef item is also needed
  to prevent looping in some configurations.  The value is of local
  significance to the client, and the server MUST threat this as an
  opaque value.  To detect loops, the server MUST inspect the
  sequence of octet strings, looking for values that it inserted as a
  client.

  If the SCVP client includes a requestorRef value in the request,
  then the SCVP server MUST return the same value in a non-cached
  response.  The SCVP server MAY omit the requestorRef value from
  cached SCVP responses.

  The requestorRef item MUST be an octet string.  No provisions are
  made to ensure uniqueness of the requestorRef octet string; however,
  all of the octets MUST have values other than zero.

3.3 requestNonce

  The optional requestNonce item contains a request identifier
  generated by the SCVP client.  If the client includes a
  requestNonce value in the request, it is expressing a preference
  the SCVP server SHOULD return a non-cached response. If the server
Freeman, Housley, & Malpani                                    [Page 30]


INTERNET DRAFT                   SCVP                      October 2004

  returns a non-cached response it MUST include the requestNonce from
  the request in the response; however, the server MAY return a
  cached success response which MUST NOT have a requestNonce.  If the
  client includes a requestNonce and also sets a wantBack of id-swb-
  nonCachedRespRequired, the client is indicating that the SCVP
  server MUST return either a non-cached response including the
  requestNonce or an error response.  The client SHOULD include a
  requestNonce item in every request to prevent an attacker from
  acting as a man-in-the-middle by replaying old responses from the
  server.  The requestNonce value SHOULD change with every request
  sent by the client.  The client MUST NOT include the wantBack of
  id-swb-nonCachedRespRequired without a requestNonce, and a server
  receiving such a request SHOULD return an invalidRequest error
  response.

  The requestNonce item, if present, MUST be an octet string that was
  generated exclusively for this request.

3.4 requestExtensions

  The OPTIONAL requestExtensions item contains Extensions.  If
  present, each Extension in the sequence extends the request.  This
  specification does not define any extensions, the facility is
  provided to allow future specifications to extend the SCVP.  The
  syntax for Extensions is imported from [PKIX-1].  The
  requestExtensionscvRequestExtensions item, when present, MUST
  contain a sequence of extension items, and each of extension MUST
  contain extnID, critical, and extnValue items.  Each of these is
  described in the following sections.

3.4.1 extnID

  The extnID item is an identifier for the extension.  It contains
  the object identifier that names the extension.

3.4.2 critical

  The critical item is a BOOLEAN.  Each extension is designated as
  either critical (with a value of TRUE) or non-critical (with a
  value of FALSE).  By default, the extension is non-critical.  An
  SCVP server MUST reject the query if it encounters a critical
  extension it does not recognize. A non-critical extension MAY be
  ignored if it is not recognized, but MUST be processed if it is
  recognized.

3.4.3 extnValue

  The extnValue item contains an octet string.  Within the octet
  string is the extension value.  An ASN.1 type is specified for each
  extension, identified by the associated extnID object identifier.

Freeman, Housley, & Malpani                                    [Page 31]


INTERNET DRAFT                   SCVP                      October 2004

3.5 dhPublicKey
  The dhPublicKey item is an optional Diffie-Hellamn public value. It
  is defined in PKIX-ALGS. When used in conjunction with the servers
  Diffie-Hellamn value it allows the client and server to compute a
  shared secret which can be used to integrity protect the SCVP
  request-response pair. If the client is not using a protected
  transport such as TLS, an does not have another mechanism to
  integrity protect the request-response pair such as a Kerberos
  session key or a signing public key, then the client SHOULD
  generate a DH key with the same parameters as the servers (see
  section Error! Reference source not found.) and use this to
  generate the shared secret with the servers public values and
  submit an authenticatedData request using the calculated shared
  secret for the HMAC secret. For the server to compute the shared
  secret, it must lean the public values the client generates,
  therefore the client MUST include this in the request if it uses
  this mechanism to integrity protect the request-response pair. The
  reuse by the client of the generated DH key across multiple
  requests is a matter of local policy.

3.6 SCVP Request Authentication

  It is a matter of local policy what validation policy is used by
  the server when validating requests.  When validating signed SCVP
  requests, the SCVP servers SHOULD use the validation algorithm
  defined in section 6 of PKIX-1.


  If the certificate used to validate a SignedData validation request
  includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST
  have either the digital signature bit set, the non-repudiation bit
  set, or both bits set.

  If the certificate used to validate an AuthenticatedData validation
  request includes the key usage extension, it MUST have the key
  agreement bit set.

  If the certificates used on a validation request contains the
  extended Key Usage extension [PKIX-1, section 4.2.1.13], it is a
  matter of local policy which OID, if any, the server will check in
  the extension. The SCVP server MAY require the following OID

  id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

  id-kp-scvpClient             OBJECT IDENTIFIER ::= { id-kp 16 }

  If a signed request fails to meet the validation policy of the
  server, it MUST be treated as an unauthenticated request.

4 Validation Response

Freeman, Housley, & Malpani                                    [Page 32]


INTERNET DRAFT                   SCVP                      October 2004

  A SCVP server response to the client MUST be a single CVResponse
  item.  When a CVResponse is encapsulated in a MIME body part,
  application/cv-response MUST be used.

  There are a number of forms of an SCVP response:

     1. A success response to a request made over a protected
        transport such as TLS. These responses SHOULD be unsigned by
        the server

     2. A success response to a request that has SignResponse set to
        FALSE. These responses SHOULD be unsigned by the server.

     3. All other success responses MUST be signed by the server. If
        the server is unable to return a signed success response due
        to local policy, then it MUST return an error response.

     4. A error response to a request made over a protected
        transport such as TLS. These responses SHOULD be unsigned by
        the server

     5. A error response to a request that has SignResponse set to
        FALSE. These responses SHOULD be unsigned by the server.

     6. An error response to an authenticated request. These
        responses MUST be signed by the server.

     7. An error response to an authenticatedData HMAC request where
        HMAC is valid. These responses MUST be signed by the server.

     8. All other error responses MUST NOT be signed by the server.

  Successful responses are be made when the server has fully complied
  with the request.  That is, the server was able to build a
  certification path using the referenced or supplied validation
  policy, and it was able to comply with all the requested parameters.
  If the server is unable to build a certification path using the
  required validation policy or the request contains an unsupported
  option, then the server MUST return an error response.

  For signed requests and responses, SCVP servers MUST support
  SignedData, and AuthenticatedData.  It is a matter of local policy
  which types are used.

  If the server is making a signed response to a signed request, then
  the server MUST use the same signature type (SignedData or
  AuthenticatedData) as in the request.

  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.
Freeman, Housley, & Malpani                                    [Page 33]


INTERNET DRAFT                   SCVP                      October 2004


    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 an AuthenticatedData which is in turn encapsulated
  in a ContentInfo.  An overview of the structure used for a signed
  response is provided below.  As above, 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           [0] IMPLICIT CertificateSet OPTIONAL,
                                 -- MUST include server cert
    crls                   [1] IMPLICIT CertificateRevocationLists
                                 OPTIONAL,
    signerInfos                SET OF SignerInfos }
                                 -- Only one in SCVP

    SignerInfo {
      version                  CMSVersion,
      sid                      SignerIdentifier,
      digestAlgorithm          DigestAlgorithmIdentifier,
      signedAttrs              SignedAttributes,
                                 -- Required by CMS
      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 CVResponse

  AuthenticatedData Example:

    ContentInfo {
      contentType       id-ct-authData,
                                   -- (1.2.840.113549.1.9.16.1.2)
      content           AuthenticatedData }
Freeman, Housley, & Malpani                                    [Page 34]


INTERNET DRAFT                   SCVP                      October 2004


  AuthenticatedData ::= SEQUENCE {
    version                    CMSVersion,
    originatorInfo             OriginatorInfo,
    recipientInfos             RecipientInfos,
                                 -- Only for SCVP client
    macAlgorithm               MessageAuthenticationCodeAlgorithm,
    digestAlgorithm            DigestAlgorithmIdentifier,
    encapContentInfo           EncapsulatedContentInfo,
    authAttrs                  AuthAttributes,
                                  -- Required by CMS
    mac                        MessageAuthenticationCode,
    unauthAttrs                UnauthAttributes }
                                  -- Not used in SCVP

  EncapsulatedContentInfo {
      eContentType       id-ct-scvp-psResponse,
                                    -- (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], and it SHOULD include
  the signing-certificate attribute as defined in [ESS].  Within the
  signing-certificate attribute, the first certificate identified in
  the sequence of certificate identifiers MUST be the certificate of
  the SCVP server.  The inclusion of other certificate identifiers in
  the signing-certificate attribute is OPTIONAL.  The inclusion of
  policies in the signing-certificate is OPTIONAL.

  The CVResponse item contains the server response.  The CVResponse
  MUST contain the cvRespVersion, policyID, producedAt, and
  respStatus items.  The CVResponse MAY also contain the
  respValidationPolicy, requestorRef, requestorName, responder,
  replyObjects, respNonce, serverContextInfo, and respExtensions
  optional items.  The replyObjects item MUST contain exactly one
  CertReply item for each certificate requested.  The requestorRef
  and the responder items MUST be included if the request included a
  requestor item.  The respNonce item MUST be included if the request
  included a requestNonce item and a non-cached response is provided.

  The CVResponse MUST have the following syntax:

    CVResponse ::= SEQUENCE {
      cvResponseVersion         cvResponseVersion        INTEGER,
      policyID                  INTEGER,
      producedAt                GeneralizedTime,
Freeman, Housley, & Malpani                                    [Page 35]


INTERNET DRAFT                   SCVP                      October 2004

      responseStatus            ResponseStatus,
      respValidationPolicy  [0] RespValPolicy OPTIONAL,
      requestRef            [1] RequestReference OPTIONAL,
      requestorRef          [2] OCTET STRING OPTIONAL,
      requestorName         [3] GeneralNames OPTIONAL,
      responder             [4] OCTET STRING OPTIONAL,
      replyObjects          [5] ReplyObjects OPTIONAL,
      respNonce             [6] OCTET STRING OPTIONAL,
      serverContextInfo     [7] OCTET STRING OPTIONAL,
      cvResponseExtensions  [8] Extensions OPTIONAL }

4.1 cvResponseVersion

  The syntax and semantics of cvResponseVersion are the same as
  cvRequestVersion item is described in section 3.1.  The
  cvResponseVersion MUST match the cvRequestVersion in the request.
  If the server cannot generate a response with a matching version
  number, then the server MUST return an error response that
  indicates the highest version number that the server supports as
  the version number.

4.2 policyID

  The policy ID used by the SCVP server when it processed the request.
  See section 6.4 for details.

4.3 producedAt

  The producedAt item tells the date and time at which the SCVP
  server generated the response.  The producedAt item represents the
  date and time in UTC, using the GeneralizedTime type, and this
  value is independent of the validation time.

  GeneralizedTime value MUST be expressed in UTC, and it MUST be
  interpreted as defined in section 3.1.8.

4.4 responseStatus

  The responseStatus item gives status information to the SCVP client
  about its request.  The responseStatus item has a numeric status
  code and an optional string that is a sequence of characters from
  the ISO/IEC 10646-1 character set encoded with the UTF-8
  transformation format defined in [UTF8].

  The string MAY be used to transmit status information.  The client
  MAY choose to display the string to a human user.  However, because
  there is often no way to know the languages understood by a human
  user, the string may be of little or no assistance.

  The responseStatus item uses the responseStatus type, which has the
  following syntax:
Freeman, Housley, & Malpani                                    [Page 36]


INTERNET DRAFT                   SCVP                      October 2004


    ResponseStatus ::= SEQUENCE {
      statusCode            CVStatusCode,
      errorMessage      [0] UTF8String OPTIONAL }

    CVStatusCode ::= ENUMERATED {
      okay                        (0),
      skipUnrecognizedItems       (1),
      tooBusy                    (10),
      invalidRequest             (11),
      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),
      unrecognizedValPol         (50),
      unrecognizedValAlg         (51),
      fullRequestRefUnsuported   (52),
      fullPolResponseUnsuported  (53),
      inhibitPolMapUnsuported    (54),
      requireExpPolUnsuported    (55),
      ignoreAnyPolUnsuported     (56),
      validityTimeUnsuported     (57),
      unrecognizedUserPolOID     (60),
      unrecognizedValPolOID      (61),
      unrecognizedValAlgOID      (62),
      unrecognizedCritQueryExt   (63),
      unrecognizedCritRequestExt (64)}

  The CVStatusCode values have the following meaning:

    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.
    11 The server was able to decode the request, but there was
       some other problem with the request.
    12 An internal server error occurred.
    20 The structure of the request was wrong.
    21 The version of request is not supported by this server.
    22 The request included unrecognized items, and the server was
       not able to continue processing.
    23 The key given in the RequestSignature is not recognized.
Freeman, Housley, & Malpani                                    [Page 37]


INTERNET DRAFT                   SCVP                      October 2004

    24 The signature or message authentication code did not match
       the body of the request.
    25 The encoding was not understood.
    26 The request was not authorized.
    27 The request included unsupported checks items, and the
       server was not able to continue processing.
    28 The request included unsupported want back items, and the
       server was not able to continue processing.
    29 The server does not support the signature or message
       authentication code algorithm used by the client to sign the
       request.
    30 The server could not validate the client's signature or
       message authentication code on the request.
    40 The request was previously relayed by the same server.
    50 The request contained an unrecognized validation policy
       reference.
    51 The request contained an unrecognized validation algorithm
       OID.
    52 The server does not support returning the full request in
       the response.
    53 The server does not support returning the full validation
       policy by value in the response.
    54 The server does not support inhibiting policy mapping.
    55 The server does not support requiring explicit policy.
    56 The server does not support ignoring the any-policy
       certificate policy OID.
    57 The server only validates requests using current time.
    60 The certificate policy OID is not recognized.
    61 The validation policy OID or URI is not recognized.
    62 The validation algorithm OID is not recognized.
    63 The query item in the request contains a critical extension
       whose OID is not recognized.
    64 The request contains a critical request extension whose OID
       is not recognized.

  Status codes 0-9 are reserved for codes where the request was
  processed by the server and therefore MUST be sent in a success
  response.  Status codes 10 and above indicate an error and MUST
  therefore be sent in an unsigned error response.

4.5 respValidationPolicy

  The respValidationPolicy item contains either a reference to the
  full validation policy or the full policy by value used by the
  server to validate the request.  It MUST be present in success
  responses and MUST NOT be present in error responses.  The choice
  between retuning either the policy by reference or by value is
  controlled by the fullPolicyResponse.  The resultant validation
  policy is the union of the following:

Freeman, Housley, & Malpani                                    [Page 38]


INTERNET DRAFT                   SCVP                      October 2004

     1.  Values from the validation policy specified by reference in
     the request.

     2.. Values from the request.

     3.  Default values used by the server for any parameter not
     specified by 1 or 2.


  The respValidationPolicy syntax is:

  RespValidationPolicy ::= SEQUENCE {
    validationPolRef           ValidationPolRef,
    validationPolValues    [0] ValidationPolValues OPTIONAL,
    userFinalPolicySet     [1] SEQUENCE SIZE (1..MAX) OF
                                 OBJECT IDENTIFIER OPTIONAL,
    permittedSubtrees      [2] SEQUENCE SIZE (1..MAX) OF
                                 GeneralNames OPTIONAL,
    excludedSubtrees       [3] SEQUENCE SIZE (1..MAX) OF
                                GeneralNames OPTIONAL }

4.5.1 validationPolRef

  The validationPolRef item is defined in section 3.1.4.1.

4.5.2 validationPolValues

  If a client request the validation policy by values instead of by
  reference then the server uses the validationPolicyValues structure
  to communicate the policy values it used to validate the request.

  The validationPolValues syntax is:

  ValidationPolValues ::=SEQUENCE  {
    validationAlg            ValidationAlg,
    inhibitPolMap            BOOLEAN,
    requireExplicitPol       BOOLEAN,
    inhibitAnyPol            BOOLEAN,
    isCA                     BOOLEAN,
    trustAnchors             TrustAnchors,
    keyUsage             [0] KeyUsage OPTIONAL,
    extendedKeyUsage     [1] ExtKeyUsageSyntax OPTIONAL,
    validationPolicyAttr [2] SEQUENCE SIZE (1..MAX) OF Attribute
                             OPTIONAL }

  The optional keyUsage and ExtendedKeyUsage values are only
  necessary if there defined in the referenced policy or the client
  stated some requirements in the request.

  Each of these items is discussed in the following sections.

Freeman, Housley, & Malpani                                    [Page 39]


INTERNET DRAFT                   SCVP                      October 2004

4.5.2.1 validationAlg

  The validationAlg item is defined in section 3.1.5.2.

4.5.2.2 inhibitPolMap

  The inhibitPolMap item is defined in section 3.1.5.4.

4.5.2.3 requireExplicitPol

  The requireExplicitPol item is defined in section 3.1.5.5.

4.5.2.4 inhibitAnyPol

  The inhibitAnyPol item is defined in section 3.1.5.6.

4.5.2.5 isCA

  The isCA item is defined in section 3.1.5.7.

4.5.2.6 trustAnchors

  The trustAnchors item is defined in section 3.1.5.8.

4.5.2.7 keyUsage

  The optional keyUsage item is defined in [PKIX-1].

4.5.2.8 extendedKeyUsage

  The optional extendedKeyUsage item is defined in [PKIX-1].]3.1.5.4

4.5.2.9 validationPolicyAttr

  The validationPolicyAtt item MAY contain Attributes.  If present,
  each attribute in the sequence extends the policy values for the
  validation policy.  This specification does not define any
  attributes.  The facility is provided to allow future
  specifications to extend the SCVP.  The syntax for Attribute is
  imported from [CMS].

4.5.3 userFinalPolicySet

  The userFinalPolicySet contains the set of valid policy OIDs from
  the valid-policy-tree as defined in [PKIX-1] section 6.  The
  userFinalPolicySet MUST be populated if the valid-policy-tree from
  the validation is not NULL.  userFinalPolicySet MUST be absent if
  the valid-policy-tree from the validation is NULL.

4.5.4 permittedSubtrees

Freeman, Housley, & Malpani                                    [Page 40]


INTERNET DRAFT                   SCVP                      October 2004

  permittedSubtrees is defined in [PKIX-1] section 6.1.2, This field
  MUST be populated when isCA is TRUE in the request and the
  validated path contains a non empty permitted-subtrees value. This
  field MAY be populated for other requests when the validated path
  contains a non empty permitted-subtrees value.

4.5.5 excludedSubtrees

  excludedSubtrees is defined in [PKIX-1] section 6.1.2, This field
  MUST be populated when isCA is TRUE in the request and the
  validated path contains a non empty excluded-subtrees value. This
  field MAY be populated for other requests when the validated path
  contains a non empty excluded-subtrees value.

4.5.6 validationPolicyAtt

  The validationPolicyAtt item MAY contain Attributes.  If present,
  each attribute in the sequence extends the policy values for the
  validation policy.  This specification does not define any
  attributes. The facility is provided to allow future specifications
  to extend the SCVP.  The syntax for Attributes is imported from
  [CMS].

4.6 requestRef

  The requestRef allows the SCVP client to identify the request that
  corresponds to this response from the server.  It associates the
  response to a particular request using either a hash of the request
  or a copy of CVRequest from the request.  The hash is calculated as
  described in [CMS] for SignedData and AuthenticatedData.  That is,
  it covers the encapsulated content and authenticated attributes but
  not the unauthenticated attributes.

  The requestRef item does not provide authentication, but the
  requestRef does allow the client to determine that the request was
  not maliciously modified.

  The requestRef item allows the client to associate a response with
  a request.  The requestNonce provides an alternative mechanism for
  matching requests and responses if the client has selected to
  include a full response.  When the fullRequest alternative is used,
  the response provides a single data structure that is suitable for
  archive of the transaction.

  The requestRef item uses the RequestReference type, which has the
  following syntax:

    RequestReference ::= CHOICE {
      requestHash       [0] HashValue, -- hash of CVRequest
      fullRequest       [1] CVRequest }

Freeman, Housley, & Malpani                                    [Page 41]


INTERNET DRAFT                   SCVP                      October 2004

  SCVP clients MUST support requestHash, and they MAY support
  fullRequest.  SCVP servers MUST support using requestHash, and they
  SHOULD support using fullRequest.

4.6.1 requestHash

  The requestHash item is the hash of the CVRequest.  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.  The requestNonce provides an
  alternative mechanism for matching requests and responses.

  The requestHash item uses the HashValue type, which has the
  following syntax:

    HashValue ::= SEQUENCE {
      algorithm             AlgorithmIdentifier DEFAULT { sha-1 },
      value                 OCTET STRING }

    sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 26 }

  The algorithm identifier for SHA-1 is imported from [PKIX-ALG].  It
  is repeated here for convenience.

4.6.2 fullRequest

  Like requestHash, the fullRequest alternative allows a client to
  determine that the request was not maliciously modified.  It also
  provides a single data structure that is suitable for archive of
  the transaction.

  The fullRequest item uses the CVRequest type.  The syntax and
  semantics of the CVRequest type are described in section 3.

4.7 requestorRef

  The optional requestorRef item is used by the client to identify
  the original requestor in cases where SCVP relay is used.  The
  value is only of local significance to the client.  If the SCVP
  client includes a requestorRef value in the request, then the SCVP
  server MUST return the same value if the server is generating a,
  non-cached response.

4.8 requestorName

  The optional requestorName item is used by the server with signed
  requests to return the identity of the client in the response.
Freeman, Housley, & Malpani                                    [Page 42]


INTERNET DRAFT                   SCVP                      October 2004

  Mechanisms for matching this identifier with the authenticated
  identity are a matter of local server policy.

  In the case of non-cached responses to signed requests, the SCVP
  server MUST return a requestor name.  A server SHOULD copy the
  selected identifier from a certificate or other credential used to
  authenticate the request.  A SCVP server MAY use a client
  identifier from an out-of-band mechanism or omit the identifier
  from the response.

  In the case of cached responses to signed requests, the
  RequestorName MAY be present in the response.

  SCVP server that supports signed requests MUST support this item.

4.9 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 item MUST be included if the request included a
  requestorRef item.

  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.10 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,
  replyWantBacks, and valdationPolicy items; and the CertReply item
  MAY contain the nextUpdate and certReplyExtensions items.

  A success 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:
Freeman, Housley, & Malpani                                    [Page 43]


INTERNET DRAFT                   SCVP                      October 2004


    ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply

    CertReply ::= SEQUENCE {
      cert                       CertReference,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                   OBJECT IDENTIFIER OPTIONAL,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

4.10.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].

4.10.2 replyStatus

  The replyStatus item gives status information to the client about
  the request for the specific certificate.  Note that the respStatus
  item is different than the replyStatus item.  The respStatus item
  is the status of the whole request, while the replyStatus item is
  the status for the individual query item.

  The replyStatus item uses the ReplyStatus type, which has the
  following syntax:

    ReplyStatus ::= ENUMERATED {
        success                  (0),
        malformedPKC             (1),
        malformedAC              (2),
        unavailableValidityTime  (3),
        referenceCertHashFail    (4),
        certPathConstructFail    (5),
        certPathNotValid         (6),
        certPathNotValidNow      (7) }

  The meaning of the various ReplyStatus values are:

    0  Success: a definitive answer follows.
    1  Failure: the public key certificate was malformed.
    2  Failure: the attribute certificate was malformed.
    3  Failure: historical data for the requested validity time is
       not available.
Freeman, Housley, & Malpani                                    [Page 44]


INTERNET DRAFT                   SCVP                      October 2004

    4  Failure: the referenced certificate policy OID is not
       recognized.
    5  Failure: no certification path could be constructed.
    6  Failure: the constructed certification path is invalid.
    7  Failure: the constructed certification path is invalid, but
       a query at a later time may be successful.

  Codes 1 and 2 are used to tell the client that the request was
  properly formed, but the certificate in question was not.  This is
  especially useful to clients that do not parse certificates.

4.10.3 replyValTime

  The replyValTime item tells the time at which the information in
  the CertReply was correct.  The replyValTime item represents the
  date and time in UTC, using GeneralizedTime type.  The encoding
  rules for GeneralizedTime in section 3.1.8 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 the 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.10.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:
Freeman, Housley, & Malpani                                    [Page 45]


INTERNET DRAFT                   SCVP                      October 2004


      0: Built a path
      1: Could not build a path

  The status value for public key certification path building to a
  trusted root along with simple validation processing, { id-stc 2 },
  can be one of the following:

      0: Valid
      1: Not valid

  The status value for public key certification path building to a
  trusted root along with complete status checking, { id-stc 3 }, can
  be one of the following:

      0: Good
      1: Revoked
      2: Revocation Offline
      3: Revocation Unavailable

  Revocation offline means that the server or distribution point for
  the revocation information was connected to successfully without a
  network error but either no data returned or if data was returned
  it was stale. Revocation unavailable means that a network error was
  returned when an attempt was made to reach the server or
  distribution point.

  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: Revocation Offline
      3: Revocation 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
Freeman, Housley, & Malpani                                    [Page 46]


INTERNET DRAFT                   SCVP                      October 2004

  complete status checking, { id-stc 7 }, can be one of the
  following:

      0: Good
      1: Revoked
      2: Offline
      3: Unavailable

4.10.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.

  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 section3.1.9.

  The octet string value for the proof of revocation status, { id-swb
  2 }, contains the RevocationInfos type.  The syntax and semantics
  of the RevocationInfo type are described in section 3.1.10.

  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.1.9.

Freeman, Housley, & Malpani                                    [Page 47]


INTERNET DRAFT                   SCVP                      October 2004

  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.1.10.

  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.1.10.

  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.10.6 validationAlg

  The validationAlg item indicates the validation algorithm used by
  the SCVP server.   The server MUST include the validation algorithm
  that was used.

  The syntax and semantics of the validationAlg item are descried in
  section 3.1.5.2
4.10.7 validationErrors

  The validationErrors item  MUST only be present in failure
  responses. It MUST contains one or more OID representing the why
  the validation failed.

4.10.8 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 3.1.8 MUST be used.

4.10.9 certReplyExtensions

  The certReplyExtensions contains the responses to the
  queryExtension item in the request.  The certReplyExtensions 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.

Freeman, Housley, & Malpani                                    [Page 48]


INTERNET DRAFT                   SCVP                      October 2004

  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.11 responseNonce

  The responseNonce item contains an identifier to binds the request
  to the response.

     If the client includes a requestNonce value in the request and
     the server is generating a specific non-cached response to the
     request then the server MUST return the same value in the
     response.

     If the server is using a cached response to the request then it
     MUST omit the responseNonce field.

     If the server is returning a specific non-cached response to a
     request without a once, then the server MUST use value of the
     message-digest attribute in the signedAttrs within SignerInfo of
     the request as the value in the responseNonce field.

  The requestNonce item uses the octet string type.

  Client SHOULD support and servers MUST support responseNonce.

4.12 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 certification path retuned, it can
  make a new query and pass along this context information.

  Section 3.1.6 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 been 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.

Freeman, Housley, & Malpani                                    [Page 49]


INTERNET DRAFT                   SCVP                      October 2004

  Servers that are incapable of returning additional paths MUST NOT
  include the serverContextInfo item in the response.

4.13 respExtensions

  The respExtensions item MAY contain Extensions.  If present, each
  Extension in the sequence extends the response.  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.

4.14 SCVP Response Validation

  There are two mechanisms for validation of SCVP responses, one
  based on the clients knowledge of a specific SCVP server key and
  the other based on validation of the certificate which signed the
  SCVP response

4.14.1 Simple Key Validation

  Simple key validation method is where the SCVP client has a local
  policy of one or more SCVP server keys which directly identify the
  set of valid SCVP servers. Mechanisms for storage of server keys or
  identifiers is a local matter. For example, a client could store
  cryptographic hashes of public keys used to verify signedData
  responses. Alternatively, a client could store shared symmetric
  keys used to HMAC authenticatedData responses.

  Simple key validation MUST be used by SCVP clients that cannot
  validate PKIX-1 certificates and are therefore making delegated
  path validation requests to the SCVP server[RQTMS]. It is a matter
  of local policy with these clients whether to use signedData or
  authenticatedData. Simple key validation MAY be used by other SCVP
  clients for other reasons.


Freeman, Housley, & Malpani                                    [Page 50]


INTERNET DRAFT                   SCVP                      October 2004

4.14.2 SCVP Server Certificate Validation

  It is a matter of local policy what validation policy is used by
  the client when validating responses. When validating signed SCVP
  responses, SCVP clients SHOULD use the validation algorithm defined
  in section 6 of PKIX-1.

  If the certificate used to sign the validation policy responses and
  signedData validation responses contains the key usage extension
  [PKIX-1 section 4.2.1.3] it MUST have either the digital signature
  or the non-repudiation bits set or both.

  If the certificate for authenticatedData validation responses
  contains the key usage extension it MUST have the key agreement bit
  set.

  If the certificates used on a validation policy response or a
  validation response contains the extended Key Usage extension
  [PKIX-1 section 4.2.1.13] it MUST contain the following OID

  id-kp-scvpServer             OBJECT IDENTIFIER ::= { id-kp 15 }

5 Server Policy Request

  A SCVP client uses the valPolRequest item to request the list of
  validation policies supported by the SCVP server.  When a
  valPolRequest is encapsulated in a MIME body part, it MUST be
  carried in an application/vp-request MIME body part.

  The request consists of a valPolRequest encapsulated in a
  ContentInfo.  The request is not signed by the client.

    ContentInfo {
      contentType        id-ct-scvp-valPolRequest,
                                    -- (1.2.840.113549.1.9.16.1.12)
      content            valPolRequest }

  The valPolRequest type has the following syntax:

  VPRequest ::= SEQUENCE {
    vpRequestVersion           INTEGER,
    requestNonce               OCTET STRING}

5.1 vpRequestVersion

  The vpRequestVersion item is described in section 3.1.requestNonce

5.2 requestNonce

  The requestNonce item contains a request identifier generated by
  the SCVP client.  If the server returns a specific response it MUST
Freeman, Housley, & Malpani                                    [Page 51]


INTERNET DRAFT                   SCVP                      October 2004

  include the requestNonce from the request in the response, but MAY
  return a cached response which MUST NOT include a requestNonce.

6 Validation Policy Response

  In response to a valPolRequest, the SCVP server provides a
  valPolResponse. The valPolResponse MAY not unique to any
  valPolRequest, so may be reused by the server in response to
  multiple vbalPolRequests. The valPolResponse also has an indication
  of how frequently the valPolResponse may be reissued. When a
  PolResponse is encapsulated in a MIME body part, it MUST be carried
  in an application/vp-response MIME body part.

  The response consists of a valPolResponse encapsulated in a
  ContentInfo.  The response MUST be signed by the server using its
  digital signature certificate.

    ContentInfo {
      contentType        id-ct-scvp-valPolResponse,
                                    -- (1.2.840.113549.1.9.16.1.13)
      content            valPolResponse }

  The valPolResponse type has the following syntax:

    VPResponse ::= SEQUENCE {
      vpResponseVersion          INTEGER,
      maxCVResponseVersion       INTEGER,
      maxVPResponseVersion       INTEGER,
      defaultPolicyID            INTEGER,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime OPTIONAL,
      validationPolices          SEQUENCE OF ValidationPolRef,
      validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
      authPolicies               SEQUENCE OF AuthPolicy,
      responseTypes              ResponseTypes,
      defaultPolicyValues        ValidationPolValues,
      dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
      clockSkew              [0] INTEGER OPTIONAL,
      requestNonce           [1] OCTET STRING OPTIONAL }

  ResponseTypes  ::= ENUMERATED {
    cached-only                (0),
    specific-signed-only       (1),
    cached-and-specific-signed (2)}


  SCVP clients that support validation policy requests MUST support
  SCVP responses. SCVP servers MUST support validation policy
  responses.

Freeman, Housley, & Malpani                                    [Page 52]


INTERNET DRAFT                   SCVP                      October 2004

  SCVP servers MUST support cached policy responses and MAY support
  specific responses to policy request.

6.1 vpResponseVersion

  The syntax and semantics of the vpResponseVersion item is described
  in section 3.1. The vpResponseVersion used MUST be the same as the
  vpRequestVersion unless the client has used a value grater than the
  values the server supports. If the client submits a
  vpRequestVersion grater then the version supported by the server,
  it MUST return an a vpResponseVersion using the highest version
  number the server supports as the version number.

6.2 maxCVRequestVersion

  The maxCVRequestVersion defines the maximum version number for CV
  requests that the server supports

6.3 maxVPRequestVersion

  The maxVPRequestVersion defines the maximum version number for VP
  requests that the server supports


6.4 defaultPolicyID

  An integer that uniquely represents the version of the default
  validation policy as represented by the trustAnchors,
  validationPolicy, validationAlg, authPolicies, clockSkew and
  authDataCerts. If any of these values change, the server MUST
  create a new PolResponse with a new defaultPolicyID. If the policy
  and therefore the defaultPolicyID has not changed, then the server
  may reused defaultPolicyID across multiple PolResponse messages.
  However if the server having changed the policy, then reverts to an
  earlier policy, the server MUST NOT revert the policy ID as well,
  but MUST select another unique value.

6.5 thisUpdate

  This field indicates the signing date & time of this policy
  response.

  GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)
  and interpreted as defined in section 3.1.8.

6.6 nextUpdate

  This optional field indicates the expected publication date & time
  of the next policy response.

Freeman, Housley, & Malpani                                    [Page 53]


INTERNET DRAFT                   SCVP                      October 2004

  If this field is omitted it indicates a non-cached response
  generated in response to a specific request, then the polResponse
  is bound to a specific request. If this filed is omitted the
  requestNonce files MUST be present and the value copied from the
  request.

  If this field is preset it indicates a non-cached response, then
  the polResponse is not bound to a specific request. A SCVP server
  MUST periodically generate the new response as defined by the next
  update time and use the same polResponse used for multiple requests.

  It is a matter of local server policy to return a cached or non-
  cached specific response.

  GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)
  as specified in section 3.1.8.

6.7 trustAnchors

  The trustAnchors item specifies the default trust anchors that the
  SCVP server will use if the request references a validation policy
  which does not define any trust anchors and no trust anchors are
  present in the request.

6.8 validationPolicies

  The validationPolicies item contains a sequence of ValidationPolRef
  representing the validation policies supported by the server. It is
  a matter of local policy if the server whishes to processes
  requests using the default validation policy, and if it does not,
  then it MUST NOT include the id-svp-defaultValPolicy in this list.

6.9 validationAlgs

  The validationAlgs item contains a sequence of OIDs.  Each OID
  identifies a validation algorithm supported by the server.

6.10 authPolicies

  The authPolicies item contains a sequence of policy references for
  authenticating to the SCVP server.

  The reference to the authentication policy can be either an OID
  where the client and server have agreed the OID to represent a
  authentication policy or a URI where the URI points to a human
  readable definition of the policy. The list of policies is intended
  to document to the client if authentication is required for some
  requests and if so how.

  AuthPolicy ::= CHOICE {
      authPolRefByOID     [0] OBJECT IDENTIFIER,
Freeman, Housley, & Malpani                                    [Page 54]


INTERNET DRAFT                   SCVP                      October 2004

      authPolRefByURI     [1] IA5String}

6.11 responseTypes

  Response types allows the server to publish the range of response
  types it supports. Cache only means the server will only return
  cached responses to requests. Unique signed responses means the
  server will return a specific response to the request i.e.
  containing the requestors nonce. Both means the server will return
  either depending on the request.

6.12 dhPublicKeyInfo

  The dhPublicKeyInfo is a  sequence of one or more Diffie-Hellman
  public keys and associated parameters. It is used by clients making
  authenticatedData requests to the server. dhPublicKeyInfo has the
  following structure:

  DHPublicKeyInfo ::= SEQUENCE {
    dhPublicKey                DHPublicKey,
    domainParameters           DomainParameters}

  DHPublicKeyInformation MUST be supported by a SCVP server. SCVP
  serverS MUST support a 1536-bit MODP group key (group 5) as defined
  in [IKE-GROUPS]. SCVP servers MAY support other group keys as
  defined in [IKE] or [IKE-GROUPS].

6.13 clockSkew

  The clockSkew item is the number of minutes the server will allow
  for clock skew. If absent the server MUST use the default value of
  10 minutes.

6.14 defaultValPolicy

  This is the default validation policy used by the server. It
  contains a VaidationPolValues which is defined in section 4.5 A
  server will use these default values when

     The request references the default validation policy and the
     client does not override the defaults vaues by supplying other
     values in the request

     The request references a non-default validation policy, which
     does not define every parameter necessary as defined by the
     validation algorithm and the client further omits these missing
     values from request. The server MUST use its default value for
     any parameter not defined by the referenced non-default policy,
     and not specified in the request.

Freeman, Housley, & Malpani                                    [Page 55]


INTERNET DRAFT                   SCVP                      October 2004

  This allows the client to optimize the request by omitting
  parameters which match the server default values.

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 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 the 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 cvResponseStatus 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 }
Freeman, Housley, & Malpani                                    [Page 56]


INTERNET DRAFT                   SCVP                      October 2004


  DEFINITIONS IMPLICIT TAGS ::= BEGIN

  IMPORTS

    DHPublicKey, DomainParameters
      FROM PKIX1Algorithms88  RFC 3279
      { iso(1) identified-organization(3)
      dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-algorithms(17)

  AlgorithmIdentifier, Certificate, Extensions, GeneralNames,
    UTF8String, CertificateList, keyPurposeId
      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 }

    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 {
    cvRequestVersion           INTEGER,
    query                      Query,
    requestorRef           [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                 OPTIONAL,
    requestNonce           [1] OCTET STRING OPTIONAL,
    reqestExtensions       [2] Extensions OPTIONAL,
    dhPublicKey            [3] DHPublicKey OPTIONAL}


  Query ::= SEQUENCE {
    queriedCerts               SEQUENCE SIZE (1..MAX) OF
                                 CertReference,
    checks                     CertChecks,
    wantBack                   WantBack,
    validationPolicy           ValidationPolicy,
    responseFlags              ResponseFlags OPTIONAL,
Freeman, Housley, & Malpani                                    [Page 57]


INTERNET DRAFT                   SCVP                      October 2004

    serverContextInfo      [0] OCTET STRING OPTIONAL,
    validationTime         [1] GeneralizedTime OPTIONAL,
    intermediateCerts      [2] CertBundle OPTIONAL,
    revInfos               [3] RevocationInfos OPTIONAL,
    producedAt             [4] GeneralizedTime OPTIONAL,
    queryExtensions        [5] Extensions OPTIONAL }

  CertReference::= CHOICE {
    pkc                        PKCReference,
    ac                         ACReference }

  PKCReference ::= CHOICE {
    cert                   [0] Certificate,
    pkcRef                 [1] ESSCertID }

  ACReference ::= CHOICE {
    attrCert               [2] AttributeCertificate,
    acRef                  [3] ESSCertID }

  ValidationPolicy ::= SEQUENCE {
    validationPolRef           ValidationPolRef,
    validationAlg          [0] ValidationAlg OPTIONAL,
    userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                 IDENTIFIER OPTIONAL,
    inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
    requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
    inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
    isCA                   [5] BOOLEAN OPTIONAL,
    trustAnchors           [6] TrustAnchors OPTIONAL,
    keyUsages              [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                 OPTIONAL,
    extendedKeyUsages      [8] ExtKeyUsageSyntax OPTIONAL}


  CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

  WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

  ValidationPolRef ::= CHOICE {
    valPolRefByOID         [0] OBJECT IDENTIFIER,
    valPolRefByURI         [1] IA5String}

  ValidationAlg ::= SEQUENCE {
    valAlgId                   OBJECT IDENTIFIER,
    parameters                 ANY DEFINED BY valAlgId OPTIONAL }

  nameValidationAlg ::= SEQUENCE {
    keyPurposeId               OBJECT IDENTIFIER,
    validationName             GeneralNames }

  TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
Freeman, Housley, & Malpani                                    [Page 58]


INTERNET DRAFT                   SCVP                      October 2004


  ResponseFlags ::= SEQUENCE {
    responseRefHash            BOOLEAN DEFAULT TRUE,
    responseValidationPolByRef BOOLEAN DEFAULT TRUE,
    signResponse               BOOLEAN DEFAULT TRUE }

  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 {
    riType                     OBJECT IDENTIFIER,
    riValue                    ANY DEFINED BY riType }


   -- SCVP Certificate Validation Response

  id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }

  CVResponse ::= SEQUENCE {
    cvResponseVersion          cvResponseVersion        INTEGER,
    policyID                   INTEGER,
    producedAt                 GeneralizedTime,
    responseStatus             ResponseStatus,
    respValidationPolicy   [0] RespValPolicy OPTIONAL,
    requestRef             [1] RequestReference OPTIONAL,
    requestorRef           [2] OCTET STRING OPTIONAL,
    requestorName          [3] GeneralNames OPTIONAL,
    responder              [4] OCTET STRING OPTIONAL,
    replyObjects           [5] ReplyObjects OPTIONAL,
    respNonce              [6] OCTET STRING OPTIONAL,
    serverContextInfo      [7] OCTET STRING OPTIONAL,
    cvResponseExtensions   [8] Extensions OPTIONAL }

  responseStatus ::= SEQUENCE {
      statusCode               CVStatusCode,
      errorMessage         [0] UTF8String OPTIONAL }

  CVStatusCode ::= ENUMERATED {
      okay                        (0),
      skipUnrecognizedItems       (1),
      tooBusy                    (10),
      invalidREquest             (11),
      internalError              (12),
      badStructure               (20),
Freeman, Housley, & Malpani                                    [Page 59]


INTERNET DRAFT                   SCVP                      October 2004

      unsupportedVersion         (21),
      abortUnrecognizedItems     (22),
      unrecognizedSigKey         (23),
      badSignature               (24),
      unableToDecode             (25),
      notAuthorized              (26),
      unsupportedChecks          (27),
      unsupportedWantBacks       (28),
      unsupportedSignature       (29),
      invalidSignature           (30),
      relayingLoop               (40),
      unrecognizedValPol         (50),
      unrecognizedValAlg         (51),
      fullRequestRefUnsuported   (52},
      fullPolResponseUnsuported  (53),
      inhibitPolMapUnsuported    (54),
      requireExpPolUnsuported    (55),
      ignoreAnyPolUnsuported     (56),
      validityTimeUnsuported     (57),
      unrecognizedUserPolOID     (60),
      unrecognizedValPolOID      (61),
      unrecognizedValAlgOID      (62),
      unrecognizedCritQueryExt   (63),
      unrecognizedCriticalExt    (64)}

  RespValidationPolicy ::= SEQUENCE {
    validationPolRef           ValidationPolRef,
    validationPolValues    [0] ValidationPolValues OPTIONAL
    userFinalPolicySet     [1] SEQUENCE SIZE (1..MAX) OF
                                 OBJECT IDENTIFIER OPTIONAL
    permittedSubtrees      [2] SEQUENCE SIZE (1..MAX) OF
                                 GeneralNames OPTIONAL
    excludedSubtrees       [3] SEQUENCE SIZE (1..MAX) OF
                                GeneralNames OPTIONAL}

  ValidationPolValues ::=SEQUENCE  {
    validationAlg              ValidationAlg,
    inhibitPolMap              BOOLEAN DEFAULT FALSE,
    requireExplicitPol         BOOLEAN DEFAULT FALSE,
    inhibitAnyPol              BOOLEAN DEFAULT FALSE,
    isCA                       BOOLEAN DEFAULT FALSE,
    trustAnchors               TrustAnchors,
    keyUsage               [0] KeyUsage OPTIONAL,
    extendedKeyUsage       [1] ExtKeyUsageSyntax OPTIONAL,
    validationPolicyAtt    [2] SEQUENCE SIZE (1..MAX) OF Attribute
                                 OPTIONAL }

  RequestReference ::= CHOICE {
    requestHash            [0] HashValue, -- hash of CVRequest
    fullRequest            [1] CVRequest }

Freeman, Housley, & Malpani                                    [Page 60]


INTERNET DRAFT                   SCVP                      October 2004

  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                       CertReference,
    replyStatus                ReplyStatus,
    replyValTime               GeneralizedTime,
    replyChecks                ReplyChecks,
    replyWantBacks             ReplyWantBacks,
    validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                 OBJECT IDENTIFIER OPTIONAL,
    nextUpdate             [1] GeneralizedTime OPTIONAL,
    certReplyExtensions    [2] Extensions OPTIONAL }

  ReplyCertificate ::= CHOICE {
    pkc                    [1] Certificate,
    ac                     [2] AttributeCertificate }


  ReplyStatus ::= ENUMERATED {
    success                    (0),
    malformedPKC               (1),
    malformedAC                (2),
    unavailableValidityTime    (3),
    referenceCertHashFail      (4),
    certPathConstructFail      (5),
    certPathNotValid           (6),
    certPathNotValidNow        (7)}

  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 }

Freeman, Housley, & Malpani                                    [Page 61]


INTERNET DRAFT                   SCVP                      October 2004

  VPRequest ::= SEQUENCE {
    scvpVersion                INTEGER,
    requestNonce               OCTET STRING}

  -- SCVP Validation Policies Response

  id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }

  VPResponse ::= SEQUENCE {
    vpResponseVersion          INTEGER,
    maxCVResponseVersion       INTEGER,
    maxVPResponseVersion       INTEGER,
    defaultPolicyID            INTEGER,
    thisUpdate                 GeneralizedTime,
    nextUpdate                 GeneralizedTime OPTIONAL,
    validationPolices          SEQUENCE OF ValidationPolRef,
    validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
    authPolicies               SEQUENCE OF AuthPolicy,
    responseTypes              ResponseTypes,
    defaultValidationPolicy    ValidationPolValues,
    dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
    clockSkew              [0] INTEGER OPTIONAL,
    requestNonce           [1] OCTET STRING OPTIONAL }

  ResponseTypes  ::= ENUMERATED {
    cached-only                (0),
    specific-signed only       (1),
    cached-and-specific-signed (2)}

  DHPublicKeyInfo ::= SEQUENCE {
    dhPublicKey                DHPublicKey,
    domainParameters           DomainParameters}

  -- 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 }

  -- SCVP WantBack Identifiers

  id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  18 }
Freeman, Housley, & Malpani                                    [Page 62]


INTERNET DRAFT                   SCVP                      October 2004


   id-swb-pkc-best-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 }
   id-swb-non-cached-resp          OBJECT IDENTIFIER ::= { id-swb 9 }
   id-swb-pkc-cert                 OBJECT IDENTIFIER ::= { id-swb 10}
   id-swb-ac-cert                  OBJECT IDENTIFIER ::= { id-swb 11}
   id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}

  -- SCVP Validation Algorithm Identifiers

  id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  19 }

  id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 }

   -- SCVP Basic Validation Algorithm Identifier

    id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }

   -- SCVP Basic Validation Algorithm Errors

  id-bvae OBJECT IDENTIFIER ::= { id-svp-basicValAlg 1 }

  id-bvae-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
  id-bvae-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 }
  id-bvae-wrong-anchor         OBJECT IDENTIFIER ::= { id-bvae 3 }
  id-bvae-partial-chain        OBJECT IDENTIFIER ::= { id-bvae 4 }
  id-bvae-invalid-key-usage    OBJECT IDENTIFIER ::= { id-bvae 10 }
  id-bvae-invalid-Purpose      OBJECT IDENTIFIER ::= { id-bvae 11 }
  id-bvae-invalid-policy       OBJECT IDENTIFIER ::= { id-bvae 12 }
  id-bvae-invalid-name         OBJECT IDENTIFIER ::= { id-bvae 13 }
  id-bvae-invalid-entity       OBJECT IDENTIFIER ::= { id-bvae 14 }
  id-bvae-invalid-depth        OBJECT IDENTIFIER ::= { id-bvae 15 }

  -- SCVP Name Validation Algorithm Identifier

    id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }

  -- SCVP Name Validation Algorithm Errors

  id-nvae OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 }

  id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 }
  id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 }
Freeman, Housley, & Malpani                                    [Page 63]


INTERNET DRAFT                   SCVP                      October 2004

  id-nvae-unknown-pupose         OBJECT IDENTIFIER ::= { id-nvae 3 }
  id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 }
  id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 }
  id-nvae-mixed-names           OBJECT IDENTIFIER ::= { id-nvae 6 }


  END

9 Security Considerations

  The following are in addition to the [CMS] 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
  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.

Freeman, Housley, & Malpani                                    [Page 64]


INTERNET DRAFT                   SCVP                      October 2004

  SCVP does not include any confidentiality mechanisms.  If
  confidentiality is needed, it can be achieved with a lower-layer
  security protocol.

  The only validation policy references which are truly persistent
  are OIDs. If the ownership of the policy could in any way be an
  issue, then OIDs should be the type reference of choice. However in
  many situations, even though URIs are technically non-persistent,
  the use of an URI is much more readily understood because of its
  widespread use elsewhere, and with many organizations they may be
  viewed as persistent for practical purposes. Therefore in these
  situations use of URI many be more attractive.

  Certificate validation is expensive and there are performance
  benefits in caching and reusing the result of a validation -
                                                   -
  especially for high volume server processes. Caching end entity
  certificate would typically result in low hit rates against the
  cashe so is therefore inefficient. Caching CA certificates should
  yield much higher hit rates, but this needs to be done carefully
  because it could lead to the wrong result. One way this to achieve
  caching at the CA certificate level is to build a client which has
  enough of the chain validation logic to validate an end entity
  certificate to a CA certificate. The client can then use SCVP to
  validate the CA certificate, cache the result and locally validate
  end entity certificates against the cache of known good CA
  certificates. Attempting this kind of optimization with
  intermediate CA certificates could cause problems in some edge
  cases -
       - especially with chains involving self-issued certificates
  so caches should only be attempted with end entity issuing CA
  certificate.

  If an SCVP client is not operating on a network with good physical
  protection, it must ensure that there is integrity over the SCVP
  request\response pair and ensure that the response cannot be a
  replay of a cached response obtained by another client. It can do
  this by using a protected transport such as TLS. It can also do
  this by using the Diffie-hellman keys to sign the request. It can
  also use signing keys and request a fresh response from the server.

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.
             http://www.ietf.org/rfc/rfc2119.txt

Freeman, Housley, & Malpani                                    [Page 65]


INTERNET DRAFT                   SCVP                      October 2004

  [CMS]       Housley, R., "Cryptographic Message Syntax", RFC
             2630,June 1999.
             http://www.ietf.org/rfc/rfc2630.txt

  [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.
             http://www.ietf.org/rfc/rfc2560.txt

  [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.
             http://www.ietf.org/rfc/rfc3280.txt

  [PKIX-AC]    Farrell, S., and R.  Housley, "An Internet Attribute
             Certificate Profile for Authorization", RFC 3281,
             April 2002.
             http://www.ietf.org/rfc/rfc3281.txt

  [PKIX-ALG]   Polk, W., Housley, R.  and L.  Bassham, "Algorithms
             and Identifiers for the Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation
             List (CRL) Profile", RFC 3279, April 2002.
             http://www.ietf.org/rfc/rfc3280.txt

  [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.
             http://www.ietf.org/rfc/rfc2279.txt

  [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME",
             RFC 2634, June 1999.
             http://www.ietf.org/rfc/rfc2634.txt

  [HTTP-TLS]   Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
             http://www.ietf.org/rfc/rfc2818.txt

  [SMIME-CERT] B. Ramsdell, Ed. Secure/Multipurpose Internet Mail
             Extensions (S/MIME) Version 3.1 Certificate
             Handling RFC3850, July 2004.
             http://www.ietf.org/rfc/rfc3850.txt

  [IKE]       D. Harkins, D. Carrel. The Internet Key Exchange
             RFC2409, November 1998
             http://www.ietf.org/rfc/rfc2409.txt

Freeman, Housley, & Malpani                                    [Page 66]


INTERNET DRAFT                   SCVP                      October 2004

  [IKE-GROUPS] T. Kivinen, M. Kojo More Modular Exponential (MODP)
             Diffie-Hellman groups for Internet Key Exchange (IKE)
             RFC3526, May 2003
             http://www.ietf.org/rfc/rfc3526.txt

10.2  Informative References

  [HTTP]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
             T. Berners-Lee, "Hypertext Transfer Protocol --
             HTTP/1.1", RFC 2068, January 1997.

  [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.  Special thanks to the following for their
  contributions to this standard and diligence in greatly improving
  this document.

    Denis Pinkas
    Phillip Hallam-Baker
    Mike Myers
    Frank Balluffi
    Ameya Talwalkar
    John Thielens
    Peter Sylvester
    Yuriy Dzambasow
    Sean P. Turner
    Wen-Cheng Wang
    Francis Dupont
    Dave Engberg
    Faisal Maqsood
    David A. Cooper

  Thanks also to the workgroup chairs Tim Polk and Steve Kent in
  their support and help.

Appendix A -- MIME Registrations

  Four MIME type registrations are provided in this appendix.

 A.1 application/cv-request

  To: ietf-types@iana.org
  Subject: Registration of MIME media type application/cv-request

  MIME media type name: application

Freeman, Housley, & Malpani                                    [Page 67]


INTERNET DRAFT                   SCVP                      October 2004

  MIME subtype name: cv-request

  Required parameters: format

  Optional parameters: None

  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/cv-response

  To: ietf-types@iana.org
  Subject: Registration of MIME media type application/cv-response

  MIME media type name: application

  MIME subtype name: cv-response

  Required parameters: format

  Optional parameters: None

  Encoding considerations: binary

  Security considerations: Unless reporting an error, the response is
  cryptographically signed

  Interoperability considerations: None

Freeman, Housley, & Malpani                                    [Page 68]


INTERNET DRAFT                   SCVP                      October 2004

  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): .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/vp-request

  To: ietf-types@iana.org
  Subject: Registration of MIME media type application/vp-request

  MIME media type name: application

  MIME subtype name: vp-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>

Freeman, Housley, & Malpani                                    [Page 69]


INTERNET DRAFT                   SCVP                      October 2004

  Intended usage: COMMON

  Author/Change controller: Ambarish Malpani <ambarish@malpani.biz>

 A.4 application/vp-response

  To: ietf-types@iana.org
  Subject: Registration of MIME media type application/vp-response

  MIME media type name: application

  MIME subtype name: vp-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
Freeman, Housley, & Malpani                                    [Page 70]


INTERNET DRAFT                   SCVP                      October 2004

  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/cv-
      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 VPRequest.  Other HTTP headers MAY be present and MAY be
      ignored if not understood by the requestor.

  Sample Content-Type headers are:
         Content-Type: application/cv-policy-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/cv-
  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.

B.3 SCVP Policy Request

  HTTP based SCVP policy 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/vp-
  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 VPRequest.  Other HTTP headers MAY be present and MAY be
      ignored if not understood by the requestor.
Freeman, Housley, & Malpani                                    [Page 71]


INTERNET DRAFT                   SCVP                      October 2004


  Sample Content-Type headers are:
         Content-Type: application/vp-request

B.4 SCVP Policy Response

  An HTTP-based SCVP policy response is composed of the appropriate
  HTTP headers, followed by the binary value of the DER encoding of
  the VPResponse.

  The Content-Type header MUST have the value "application/vp-
  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

  Trevor Freeman
  Microsoft Corporation,
  One Microsoft way.
  Redmond, WA 98052
  USA.
  trevorf@microsoft.com

  Russell Housley
  Vigil Security, LLC
  918 Spring Knoll Drive
  Herndon, VA 20170
  USA
  housley@Vigilsec.com

  Ambarish Malpani
  Malpani Consulting Services
  ambarish@malpani.biz


Freeman, Housley, & Malpani                                    [Page 72]


INTERNET DRAFT                   SCVP                      October 2004

  Full Copyright Statement

  "Copyright (C) The Internet Society (2004).  This document is
  subject to the rights, licenses and restrictions contained in BCP
  78, and except as set forth therein, the authors retain all their
  rights."

  "This document and the information contained herein are provided on
  An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
  REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
  THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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."

  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 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.

Freeman, Housley, & Malpani                                    [Page 73]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/