[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                                              A. Malpani
draft-ietf-pkix-scvp-15.txt                Malpani Consulting Services
July 2004                                                   R. Housley
Expires in six months                                   Vigil Security
                                                            T. Freeman
                                                        Microsoft Corp


           Simple Certificate Validation Protocol (SCVP)


Status of this memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC 2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-Drafts
  as reference material or to cite them other than as "work in
  progress."

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

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


Copyright Notice

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

Table of Contents

1 Introduction......................................................4
 1.1 SCVP overview and requirements.................................4
 1.2 Terminology....................................................5
 1.3 Validation Policies............................................5
2 Protocol Overview.................................................6
3 Validation Request................................................7
 3.1 scvpVersion....................................................9
 3.2 Query..........................................................9
   3.2.1 queriedCerts..............................................10
   3.2.2 checks....................................................11
   3.2.3 wantBack..................................................12
   3.2.4 RequestRefHash............................................13
   3.2.5 fullPolResponse...........................................14
   3.2.6 inhibitPolMap.............................................14
   3.2.7 requireExplicitPol........................................14
   3.2.8 ignoreAnyPol..............................................14
   3.2.9 isCA......................................................15
   3.2.10 signResponse.............................................15
   3.2.11 serverContextInfo........................................15
   3.2.12 validationAlg............................................16
     3.2.12.1 Default Validation Algorithm.........................16
     3.2.12.2 Name Validation Algorithm............................17
     3.2.12.3 Name Validation Algorithm Errors.....................18
   3.2.13 validityTime.............................................18
   3.2.14 trustAnchors.............................................19
   3.2.15 intermediateCerts........................................20
   3.2.16 revInfos.................................................20
   3.2.17 keyUsage.................................................21
   3.2.18 extendedKeyUsage.........................................21
   3.2.19 queryExtensions..........................................22
   3.2.20 producedAt...............................................22
   3.2.21 validationPolRef.........................................22
 3.3 Requestor.....................................................23
 3.4 requestNonce..................................................23
 3.5 reqExtensions.................................................24
 3.6 SCVP Request Validation.......................................24
4 Validation Response..............................................25
 4.1 scvpVersion...................................................27
 4.2 policyID......................................................28
 4.3 producedAt....................................................28
 4.4 responseStatus................................................28
 4.5 requestReference..............................................29
   4.5.1 requestHash...............................................30
   4.5.2 fullRequest...............................................31
 4.6 Requestor.....................................................31
 4.7 responder.....................................................31
 4.8 replyObjects..................................................31
   4.8.1 cert......................................................32
   4.8.2 replyStatus...............................................32
Malpani, Housley, & Freeman                                    [Page2]
INTERNET DRAFT                   SCVP                      July 2004

   4.8.3 replyValTime..............................................33
   4.8.4 replyChecks...............................................33
   4.8.5 replyWantBack.............................................35
   4.8.6 validationAlg.............................................36
   4.8.7 nextUpdate................................................36
   4.8.8 certReplyExtensions.......................................36
 4.9 requestNonce..................................................37
 4.10 serverContextInfo............................................37
 4.11 valPolResponse...............................................37
 4.12 respExtensions...............................................38
 4.13 SCVP Response Validation.....................................38
   4.13.1 Simple Key Validation....................................39
   4.13.2 SCVP Server Certificate Validation.......................39
5 Server Policies Request..........................................39
6 Validation Policies Response.....................................40
 6.1 scvpVersion...................................................41
 6.2 PolicyID......................................................41
 6.3 thisUpdate....................................................41
 6.4 nextUpdate....................................................41
 6.5 trustAnchors..................................................41
 6.6 validationAlgs................................................41
 6.7 clockSkew.....................................................42
 6.8 defaultValPolicy..............................................42
7 SCVP Server Relay................................................42
8 SCVP ASN.1 Module................................................43
9 Security Considerations..........................................49
10 References......................................................50
 10.1 Normative References.........................................50
 10.2 Informative References.......................................51
11 Acknowledgments.................................................51
Appendix A -- MIME Registrations...................................52
 A.1 application/cv-request........................................52
 A.2 application/cv-response.......................................52
 A.3 application/cv-policies-request...............................53
 A.4 application/cv-policies-response..............................54
Appendix B -- SCVP over HTTP.......................................55
 B.1 SCVP Request..................................................55
Appendix C -- Author Contact Information...........................55

Malpani, Housley, & Freeman                                    [Page3]
INTERNET DRAFT                   SCVP                      July 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.

  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.

1.1 SCVP overview and requirements

  The SCVP meets the requirements documented in [RQMTS].

  The primary goals of SCVP are to make it easier to deploy PKI-
  enabled applications and to allow central administration of PKI
  policies within an organization.  SCVP can be used by clients that
  do much of the certificate processing themselves but simply want an
  untrusted server to collect information for them.  However, when
  the client has complete trust in the SCVP server, SCVP can be used
  to delegate the work of certification path construction and
  validation, and SCVP can be used to ensure that policies are
  consistently enforced throughout an organization.

  Untrusted SCVP servers can provide clients the certification paths.
  They can also provide clients revocation information, such as CRLs
  and OCSP responses, and the client needs to validate the
  certification path constructed by the SCVP server.  These services
  can be valuable to clients that do not include the protocols needed
  to find and download intermediate certificates, CRLs, and OCSP
  responses.

  Trusted SCVP servers can perform certification path construction
  and validation for the client.  For a client that uses these
  services, the client inherently trusts the SCVP server as much as
  it would its own certification path validation software (if it
Malpani, Housley, & Freeman                                    [Page4]
INTERNET DRAFT                   SCVP                      July 2004

  contained such software).  There are two main reasons that a client
  may want to trust such an SCVP server:

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

      - The client is in an organization or community that wants to
  centralize its PKI policies.  These policies might dictate which
  trust anchors are used and the types of policy checking that are
  performed during certification path validation.

1.2 Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
  this document are to be interpreted as described in [STDWORDS].

1.3 Validation Policies

  A validation policy (as defined in RFC 3379 [RQMTS]) specifies the
  rules to be used by the SCVP server when validated a certificate.
  In SCVP, a validation policy can be explicitly expressed by passing
  all the parameters in the request where the request comprises of a
  validation algorithm for certificate path processing and the input
  parameters to the algorithm. Alternatively a validation policy can
  be indirectly referenced by a mutually agreed value such as an OID
  or URL where the value indicates either are a partial or full set
  of parameters necessary to complete the validation.  The default
  inputs to the certificate 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 validation algorithm is determined by agreement between the
  client and the server and is represented as an OBJECT IDENTIFIER.
  The SCVP server can assign validation algorithm object identifiers
  which indicate that some predefined settings are used in addition
  to values provided in the SCVP request.
Malpani, Housley, & Freeman                                    [Page5]
INTERNET DRAFT                   SCVP                      July 2004


  Application-specific validation algorithms in addition to those
  defined in this document can be defined to meet specific
  requirements not covered by the default validation algorithm.  The
  validation algorithms documented here should serve as guide for the
  development of further application-specific validation algorithms.

  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.  Applications MAY place
  additional requirements on the validation algorithm.

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

  Section 5 defines the validation policies request.

Malpani, Housley, & Freeman                                    [Page6]
INTERNET DRAFT                   SCVP                      July 2004

  Section 6 defines the corresponding validation policies response.

  Appendix A registers MIME types for SCVP requests and responses,
  and Appendix B describes the use of these MIME types with HTTP.

3 Validation Request

  A SCVP client request to the server MUST be a single CVRequest item.
  When a SCVPRequest 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.  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 this structure is provided below.
  Many details are not shown, but the way that SCVP makes use of CMS
  is clearly illustrated.

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

  The signed request consists of a certValRequest encapsulated in
  either a SignedData or AuthenticatedData which is in turn
  encapsulated in a ContentInfo.   An overview of this structure is
  provided below for each of these two cases.  Again, many details
  are not shown, but the way that SCVP makes use of CMS is clearly
  illustrated.

  SignedData example:

    ContentInfo {
      contentType        id-signedData, -- (1.2.840.113549.1.7.2)
      content            SignedData }

    SignedData {
      version            CMSVersion,
      digestAlgorithms   DigestAlgorithmIdentifiers,
      encapContentInfo   EncapsulatedContentInfo,
      certificates       CertificateSet, -- Optional
      crls               CertificateRevocationLists, -- Optional
      signerInfos        SET OF SignerInfo } -- only one in SCVP

    SignerInfo {
      version            CMSVersion,
      sid                SignerIdentifier,
Malpani, Housley, & Freeman                                    [Page7]
INTERNET DRAFT                   SCVP                      July 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 public key that has been
  bound to a subject identity by a certificate conformant to the pkix
  profile[PKIX-1] and that certificate MUST be suitable for signing
  the SCVP request i.e.

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

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

Malpani, Housley, & Freeman                                    [Page8]
INTERNET DRAFT                   SCVP                      July 2004

  The client MUST put an unambiguous reference to the SCVP request
  signers 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 for CVRequest is
  defined below.  The CVRequest item contains the client request.
  The CVRequest contains the scvpVersion and query items; and the
  CVRequest MAY also contain the requestor, requestNonce, and
  reqExtensions items.

  The CVRequest MUST have the following syntax:

    CVRequest ::= SEQUENCE {
      scvpVersion           INTEGER,
      query                 Query,
      requestor         [0] OCTET STRING OPTIONAL,
      requestNonce      [1] OCTET STRING OPTIONAL,
      reqExtensions     [2] Extensions OPTIONAL }

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

3.1 scvpVersion

  The scvpVersion item tells the version of SCVP used in a request or
  a response.  The value of the scvpVersion item MUST be one (1).
  Future updates to this specification ought to specify other integer
  values.

3.2 Query

  The query specifies one or more certificates that are the object of
  the request; the certificates can be either public key certificates
  [PKIX-1] or attribute certificates [PKIX-AC].  A query MUST contain
  a sequence of one or more certificate references, checks, and
  wantBack items; and a query MAY also contain valPolicy,
  validityTime, trustAnchors, intermediateCerts, revInfos, and
  queryExtensions items.

  Query MUST have the following syntax:

    Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
Malpani, Housley, & Freeman                                    [Page9]
INTERNET DRAFT                   SCVP                      July 2004

     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

  The list of certificate references in the Query item tells the
  server the certificate(s) for which the client wants information.
  The OPTIONAL serverContextInfo item tells the server that
  additional information from a previous request-response in desired.
  The OPTIONAL validityTime item tells the date and time relative to
  which the client wants the server to perform the checks.  The
  OPTIONAL valPolicy, trustAnchors, intermediateCerts, and revInfos
  items provide context for the client request.  The OPTIONAL
  queryExtensions item provides for future expansion of the query
  syntax.

3.2.1 queriedCerts

  The queriedCerts item, using the CertReference type, identifies the
  certificate that is the object of the request.  The certificate is
  either a public key certificate or an attribute certificate.  The
  certificate is either directly included or it is referenced.  When
  referenced, a SHA-1 hash value [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              [1] Certificate,
      pkcRef            [2] ESSCertID }

    ACReference ::= CHOICE {
      attrCert          [1] AttributeCertificate,
      acRef             [2] ESSCertID }
Malpani, Housley, & Freeman                                    [Page10]
INTERNET DRAFT                   SCVP                      July 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.2.2 checks

  The checks item describes the checking that the SCVP client wants
  the SCVP server to perform on the certificate(s) in the
  queriedCerts item.  The checks item MUST contain a sequence of
  object identifiers (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 trusted root;

    - Build a validated certification path to a trusted root; and

    - Do revocation status checks on the certification path.

  For attribute certificates, OIDs are defined for the following
  checks:

    - Build a certification path to a trusted root for the AC
       issuer;

    - Build a validated certification path to a trusted root for the
       AC issuer;

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

Malpani, Housley, & Freeman                                    [Page11]
INTERNET DRAFT                   SCVP                      July 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-pkc-path         OBJECT IDENTIFIER ::= { id-stc 1 }
  id-stc-build-valid-pkc-path   OBJECT IDENTIFIER ::= { id-stc 2 }
  id-stc-build-status-checked-pkc-path
                                OBJECT IDENTIFIER ::= { id-stc 3 }
  id-stc-build-aa-path          OBJECT IDENTIFIER ::= { id-stc 4 }
  id-stc-build-valid-aa-path    OBJECT IDENTIFIER ::= { id-stc 5 }
  id-stc-build-status-checked-aa-path
                                OBJECT IDENTIFIER ::= { id-stc 6 }
  id-stc-status-check-ac-and-build-status-checked-aa-path
                                OBJECT IDENTIFIER ::= { id-stc 7 }

3.2.3 wantBack

  The wantBack item describes the kind of information the SCVP client
  wants from the SCVP server for the certificate(s) in the
  queriedCerts item.  The wantBack item MUST contain a sequence of
  object identifiers (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

Malpani, Housley, & Freeman                                    [Page12]
INTERNET DRAFT                   SCVP                      July 2004

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

    - Certification path built for the certificate;

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

    - Status indication; and

    - Public key from the certificate.

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

    - Certification path built for the AC issuer certificate;

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

    - Proof of revocation status for the attribute certificate; and

    - Status indication.

  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-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-unique-resp-required    OBJECT IDENTIFIER ::= { id-swb 9 }

3.2.4 RequestRefHash

  The requestRefHash controls how the server identifies the
  corresponding request in the response.  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,
  RequestRefHash is set to FALSE in the request.  The main reason a
  client would request the server to include the full request in the
  response is if it wanted 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.

Malpani, Housley, & Freeman                                    [Page13]
INTERNET DRAFT                   SCVP                      July 2004

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

3.2.5 fullPolResponse

  The fullPolResponse controls whether the response include by value
  the full validation policy used to process the request. By default
  the response will just contain references to all the relevant data
  items it used to construct the full validation policy for he
  request.  If the client wants the validation policy by value to be
  included by the server in the CVResponse, then the fullPolResponse
  is set to TRUE.  The main reason a client would request the server
  to include the fullPolResponse in the CVResponse is if it wanted to
  archive the request-response exchange in a single object.  That is,
  the client wants to archive a single object that include by value
  in the CVResponse  every aspect of the validation policy.

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

3.2.6 inhibitPolMap

  The inihibitPolMap 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, inhibitPolMap is set to TRUE in the request.

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

3.2.7 requireExplicitPol

  The requireExplicitPol 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
  in the certificate policies extension of valid certificates.  If
  the client wants the server to require at least one policy,
  requireExplicitPol is set to TRUE in the request.

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

3.2.8 ignoreAnyPol

Malpani, Housley, & Freeman                                    [Page14]
INTERNET DRAFT                   SCVP                      July 2004

  The ignoreAnyPol 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,
  ignoreAnyPol is set to TRUE in the request.

  SCVP clients and servers MUST support the default behavior.  SCVP
  servers SHOULD support ignoring the Any-Policy OID.  SCVP clients
  MAY support ignoring the Any-Policy OID.

3.2.9 isCA

  The isCA specifies if the clients expects the entity type of the
  subject of the certificate being validated certificate 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 it MUST set the value of
  isCA to be TRUE in the request. If the client requires the subject
  to be an end entity it MUST set the value to FALSE. If the client
  does not care it MUST omit the Boolean. If the Boolean 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
  server MUST support the isCA Boolean. SCVP client SHOULD support
  setting the value to TRUE and MAY support setting the value to
  FALSE.

3.2.10 signResponse

  The signResponse specifies if the client requires the server to
  sign a response to the validation request. If the client is
  performing full chain validation on the response and it is not
  concerned about the authenticity of the source of the data, then
  the client does not benefit from the signature on the response in
  which case it can indicate to the server that the signature is
  unnecessary via the signResponse value.

  SCVP clients that support DPD MUST support setting this value to
  FALSE. Since DPV responses must be signed, DPV only SCVP clients
  MUST NOT to support this value. SCVP servers SHOULD support
  returning unsigned responses. It is a local policy decision on the
  part of the server to return signed or unsigned responses if this
  value is set to FALSE.

3.2.11 serverContextInfo

  The serverContextInfo item, if present, contains context from a
  previous request-response exchange with the same SCVP server.  It
Malpani, Housley, & Freeman                                    [Page15]
INTERNET DRAFT                   SCVP                      July 2004

  allows the server to return more than one certification path for
  the same certificate to the client.  For example, if a server
  constructs a particular certification path for a certificate, but
  the client finds it unacceptable, the client can then send the same
  query back to the server with the serverContextInfo from the first
  response, and the server will be able to provide a different
  certification path (if another one can be found).

  Contents of the serverContextInfo are opaque to the SCVP client.
  That is, the client only knows that it needs to return the value
  provided by the server with the subsequent request to get a
  different certification path.  Note that the subsequent query needs
  be essentially identical to the previous query.  The client MUST
  NOT change any items other than:

    - requestNonce;

    - serverContextInfo; and

    - the client's signature on the request.

  SCVP servers SHOULD support serverContextInfo.  SCVP clients MAY
  support serverContextInfo

3.2.12 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.2.12.1 Default Validation Algorithm

  The client can request the SCVP server's default validation
  algorithm is used or another algorithm.  The object identifier to
  identify the default validation algorithm is:

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

Malpani, Housley, & Freeman                                    [Page16]
INTERNET DRAFT                   SCVP                      July 2004

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

  When the id-svp-defaultValAlg appears as an valAlgId, the
  parameters MUST be absent.

  SCVP servers and clients MUST support the default validation
  algorithm.  SCVP servers and clients MAY support other validation
  algorithms.

  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 certPolicies
       item associated with the selected trust anchor.  If no
       certificate policies are specified in the certPolicies item,
       then the SCVP server will use any-policy.

    -  The SCVP server will check for certificate revocation using
       CRLs, delta CRLs, OCSP responses, or any other source of
       revocation information that is available.

3.2.12.2 Name Validation Algorithm

  The name validation Algorithm allows the client to supply a name to
  the server along with an application identifier.  The application
  identifier defines the name matching rules use to compare the name
  supplied in the request with the names in the certificate being
  validated.

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

  When the id-svp- NameValAlg appears as an valAlgId, the parameters
  MUST use the NameValidationAlg syntax:

    NameValidationAlg ::= SEQUENCE {
      KeyPurposeId      OBJECT IDENTIFIER,
      ValidationNames   GeneralNames }

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

  If more than one name is supplied in the request, all names MUST be
  of the same type and be valid according to the name matching rules
  requested.

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

Malpani, Housley, & Freeman                                    [Page17]
INTERNET DRAFT                   SCVP                      July 2004

  If the KeyPurposeID supplied in the request is id-kp-mailProtection
  [PKIX-1], then GeneralNames supplied in the request MUST be a
  rfc822 name, and the matching rule MUST be a case insensitive
  comparison of the whole sting.  For example user@example.com
  matches USER@Example.COM, but not auser@example.com,
  user@mail.example.com, or user@example1.com

3.2.12.3 Name Validation Algorithm Errors

  The following errors are defined for the Name Validation Algorithm

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

  id-nvae-NameMismatch    OBJECT IDENTIFIER ::= { id-nvae 1 }
  id-nvae-NoCertName      OBJECT IDENTIFIER ::= { id-nvae 2 }
  id-nvae-UnknownPupose   OBJECT IDENTIFIER ::= { id-nvae 3 }
  id-nvae-BadName         OBJECT IDENTIFIER ::= { id-nvae 4 }
  id-nvae-BadNameType     OBJECT IDENTIFIER ::= { id-nvae 5 }
  id-nvae-MixedNames      OBJECT IDENTIFIER ::= { id-nvae 6 }

  Name mismatch means the client supplied a name with the validation
  policy, which the server recognized and the server found
  corresponding name type in the certificate, but was unable to find
  a match to the name supplied.  For example, the client supplied a
  DNS name of example1.com, the certificate contained a DNS name of
  example.com.

  NoCertName means the client supplied a name with the validation
  policy, which the server recognized, but the server could not find
  the corresponding name type in the certificate.  For example, the
  client supplied a DNS name of example1.com, the certificate only
  contained a rfc822 name of user@example.com.

  UnknownPupose means the client supplied KeyPurposeID which the
  server does not recognize.

  BadName means the client supplied either and empty or malformed
  name in the request.

  BadNameType means the client supplied an inappropriate name type
  for the key purpose.  For example, the client specified a key
  purpose ID of id-kp-serverAuth, and a rfc822 name of
  user@example.com.

  MixedNames means the client supplied multiple names in the request
  of different types.

3.2.13 validityTime

  The OPTIONAL validityTime item tells the date and time relative to
  which the SCVP client wants the server to perform the checks.  If
Malpani, Housley, & Freeman                                    [Page18]
INTERNET DRAFT                   SCVP                      July 2004

  the validityTime is not present, the server MUST perform the
  validation using the date and time at which the server processes
  the request.  If the validityTime is present, it MUST be encoded as
  GeneralizedTime.  The validityTime 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
  validityTime provided in the request if the time is within the
  clock skew of the servers current time.

  GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)
  and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
  when the number of seconds is zero.  GeneralizedTime values MUST
  NOT include fractional seconds.

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

  SCVP servers MUST apply a clock skew to the validity time to allow
  for minor time synchronization errors. The default value is 10
  minutes. If the server uses a value other than the default it MUST
  include the clock skew value in the validation policy response.

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

3.2.14 trustAnchors

  The OPTIONAL trustAnchors item specifies the trust anchors to be
  used by the SCVP server.  One or more certificate policy MAY be
  associated with each trust anchor.  If a trustAnchors item is
  present, the server MUST NOT use any certification path trust
  anchors other than those provided.

  The TrustAnchors type contains one or more trust anchor
  specification.  A certificate reference can be used to identify the
  trust anchor 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 can be provided
  as a trust anchor.

  The OPTIONAL certPolicies item specifies a list of policy
  identifiers that the SCVP server MUST use when forming and
  validating a certification path that terminates at the associated
  trust anchor.  If certPolicies is not specified, then any-policy
  MUST be used.

Malpani, Housley, & Freeman                                    [Page19]
INTERNET DRAFT                   SCVP                      July 2004

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

  TrustAnchors has the following syntax:

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

    TrustAnchor ::= SEQUENCE {
      anchor                  PKCReference,
      certPolicies        [1] SEQUENCE SIZE (1..MAX) OF
                                OBJECT IDENTIFIER OPTIONAL }
                                -- if absent, use any-policy

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

3.2.15 intermediateCerts

  The OPTIONAL intermediateCerts item helps the SCVP server create
  valid certification paths.  The intermediateCerts item, when
  present, provides certificates that the server MAY use when forming
  a certification path.  The certificates in the intermediateCerts
  item MAY be used by the server in addition to any other
  certificates that the server can access when building certification
  paths.  The intermediateCerts item, when present, MUST contain at
  least one certificate.  The intermediateCerts item MUST be
  structured as a CertBundle.  The certificates in the
  intermediateCerts MUST NOT be 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 PKCReference

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

3.2.16 revInfos

  The OPTIONAL revInfo item specifies revocation information such as
  CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP
  server MUST tolerate without error the client including revInfo in
  the request and 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,
Malpani, Housley, & Freeman                                    [Page20]
INTERNET DRAFT                   SCVP                      July 2004

  the revocation information might be associated with certificates
  that the server does not use in certification path building.

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

  CRLs, delta CRLs, and OCSP responses can be provided as revocation
  information.  If needed, additional object identifiers can be
  assigned for additional revocation information types in the future.

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

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

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

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

3.2.17 keyUsage

  The key usage extension[PKIX-1, 4.2.1.3] in the certificate defines
  the technical purpose (e.g., encipherment, signature, 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. Therefore if the client obtained the certificate in
  the context of a digital signature, they can confirm this use by
  including the keyUsage structure with the digital signature bit set.

  SCVP clients SHOULD support key usage and servers MUST support
  keyUsage.

3.2.18 extendedKeyUsage

  The extended key usage extension[PKIX-1, 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.
  Therefore if the client obtained the certificate in the context of
Malpani, Housley, & Freeman                                    [Page21]
INTERNET DRAFT                   SCVP                      July 2004

  a TLS server, they can confirm this usage by including the extended
  key usage structure with the id-kp-serverAuth object identifier.

  SCVP clients SHOULD support extendedKeyUsage and servers MUST
  support extendedKeyUsage

3.2.19 queryExtensions

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

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

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

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

3.2.20 producedAt

  If the client is allowing the SCVP server to optionally use a
  cached response the producedAt item tells the earliest date and
  time when the response MUST have be produced.  The producedAt item
  represents the date and time in UTC, using the GeneralizedTime type
  and is independent of the validation time use.

  GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu)
  and MUST be interpreted as defined in section 3.2.13

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

3.2.21 validationPolRef

  The client and server can optionally agree a set of parameters
  which may fully or partially define a validation policy. If the
  policy defiles all parameters necessary for processing an SCVP
  request, the client need only supply the certificates to be
  validated and a reference to the policy in a request. If a partial
  set of parameters has been agreed, then the client supplies the
Malpani, Housley, & Freeman                                    [Page22]
INTERNET DRAFT                   SCVP                      July 2004

  certificate to be validated, a reference to the policy plus
  whatever parameters are necessary to complete the request.

  The reference to the validation policy can be either an OID where
  the client and server have agreed the OID to represent a validation
  policy or a URI where the URI represents a human readable
  definition of the policy. The server MUST do a binary comparison
  between the policy reference supplied in the request and the set of
  configured policies. The clients or server MUST NOT dereference the
  URI during SCVP request processing. The URI is simply used as a
  reference to the policy. Clients and server MAY dereference the URI
  as part of some user interface during configuration.

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

  SCVP clients and server MUST support validationPolRef in requests.

  If there are any conflicts between the policy referenced in the
  request and any supplied values in the request then the server MUST
  return an error.

3.3 Requestor

  The OPTIONAL requestor item is a reference local to the requestor.
  The value is only of local significance to the requestor.  If the
  SCVP client includes a requestor value in the request, then the
  SCVP server MUST return the same value in a unique SCVP response.
  The SCVP server MAY omit the requestor value from cached SCVP
  responses.

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

3.4 requestNonce

  The OPTIONAL requestNonce item contains 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 specific response. If the server
  returns a specific response it MUST include the requestNonce from
  the request in the response, but 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-unique-resp-
  required, the client is indicating that the SCVP server MUST return
  either a specific response including the requestNonce or an error.
  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
Malpani, Housley, & Freeman                                    [Page23]
INTERNET DRAFT                   SCVP                      July 2004

  change with every request sent by the client. The client MUST NOT
  include the wantBack of id-swb-unique-resp-required without a
  requestNonce, and a server receiving such a request SHOULD return
  an invalidRequest error

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

3.5 reqExtensions

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

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

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

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

3.6 SCVP Request Validation

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

  If the certificate used to sign a signedData validation request has
  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 used for an authenticatedData validation request
  has 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 the server will check in the
  extension. The SCVP server MAY require the following OID
Malpani, Housley, & Freeman                                    [Page24]
INTERNET DRAFT                   SCVP                      July 2004


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

4 Validation Response

  A SCVP server response to the client MUST be a single CVResponse
  item.  A CVResponse item is carried in an application/cv-response
  MIME body part.

  There are three forms of an SCVP response

    (1)Successful responses to requests where the request has a
      SignResponse value of FALSE. These MAY be signed by the
      server.
    (2)All other successful responses. These MUST be signed by the
      server. If the server is unable to return a signed successful
      response due to local policy, it MUST return an error.
    (3)Error responses. These MUST NOT be signed by the server.

  All SCVP servers MUST support signedData and SHOULD support
  authenticatedData for signed requests and responses.  It is a
  matter of local policy which types are used.

  If the server is making an signed successful 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.

    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.

  Signed Data Example:

    ContentInfo {
      contentType        id-signedData, -- (1.2.840.113549.1.7.2)
Malpani, Housley, & Freeman                                    [Page25]
INTERNET DRAFT                   SCVP                      July 2004

      content            SignedData }

    SignedData {
      version            CMSVersion,
      digestAlgorithms   DigestAlgorithmIdentifiers,
      encapContentInfo   EncapsulatedContentInfo,
      certificates       CertificateSet, -- MUST include server cert
      crls               CertificateRevocationLists, -- Optional
      signerInfos        SET OF SignerInfos } -- Only one in SCVP

    SignerInfo {
      version            CMSVersion,
      sid                SignerIdentifier,
      digestAlgorithm    DigestAlgorithmIdentifier,
      signedAttrs        SignedAttributes, -- (Required)
      signatureAlgorithm SignatureAlgorithmIdentifier,
      signature          SignatureValue,
      unsignedAttrs      UnsignedAttributes } -- Not used in SCVP

  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 }

    AuthenticatedData ::= SEQUENCE {
      version            CMSVersion,
      originatorInfo     OriginatorInfo, -- Optional
      recipientInfos     RecipientInfos, -- Only for SCVP client
      macAlgorithm       MessageAuthenticationCodeAlgorithm,
      digestAlgorithm    DigestAlgorithmIdentifier, -- Optional
      encapContentInfo   EncapsulatedContentInfo,
      authAttrs          AuthAttributes, -- Required
      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.  The SCVP server MUST include
  its own certificate in the certificates field within
  AuthenticatedData if the HMAC key is derived using a public key
Malpani, Housley, & Freeman                                    [Page26]
INTERNET DRAFT                   SCVP                      July 2004

  from a certificate.  Other certificates can also be included.  The
  SCVP server MAY also provide one or more CRLs in the crls field
  within SignedData.

  The signedAttrs within SignerInfo MUST include the content-type and
  message-digest attributes defined in [CMS] as well as the
  SigningCertificate attribute as defined in [ESS].  Within the
  SigningCertificate attribute, the first certificate identified in
  the sequence of certificate identifiers MUST be the certificate of
  the SCVP server.  The inclusion of other certificate identifiers in
  the SigningCertificate attribute is OPTIONAL.  The inclusion of
  policies in the SigningCertificate attribute is also OPTIONAL. The
  policies item in the SigningCertificate attribute SHALL not be
  present.

  The value of the message-digest attribute in the signedAttrs within
  SignerInfo MAY be used as an identifier of the response generated
  by the SCVP server.

  The CVResponse item contains the server response.  The CVResponse
  MUST contain the scvpVersion, producedAt, responseStatus, and
  requestRef items.  The CVResponse MAY also contain the requestor,
  responder, replyObjects, requestNonce, serverContextInfo, and
  respExtensions optional items.  The replyObjects item MUST contain
  exactly one CertReply item for each certificate requested.  The
  requestor and the responder items MUST be included if the request
  included a requestor item.  The requestNonce item MUST be included
  if the request included a requestNonce item.

  The CVResponse MUST have the following syntax:

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL
      respExtensions    [8] Extensions OPTIONAL }

4.1 scvpVersion

  The syntax and semantics of the scvpVersion item is described in
  section 3.1.

Malpani, Housley, & Freeman                                    [Page27]
INTERNET DRAFT                   SCVP                      July 2004

4.2 policyID

  The policy ID used by the SCVP server when it processed the request.
  See section 6.2 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 is
  independent of the validation time use.

  GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu)
  and MUST be interpreted as defined in section 3.2.13

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 optionally be used to transmit status information.
  The client MAY choose to display the string to the human user.
  However, because there is no way to know the languages understood
  by the human user, the string may be of little or no assistance.

  The responseStatus item uses the ResponseStatus type, which has the
  following syntax:

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

    SCVPStatusCode ::= ENUMERATED {
      okay                        (0),
      skipUnrecognizedItems       (1),
      tooBusy                    (10),
      invalidRequest             (11),
      internalError              (12),
      badStructure               (20),
      unsupportedVersion         (21),
      abortUnrecognizedItems     (22),
      unrecognizedSigKey         (23),
      badSignature               (24),
      unableToDecode             (25),
      notAuthorized              (26),
      unsupportedChecks          (27),
      unsupportedWantBacks       (28),
      unsupportedSignature       (29),
Malpani, Housley, & Freeman                                    [Page28]
INTERNET DRAFT                   SCVP                      July 2004

      invalidSignature           (30),
      relayingLoop               (40),
      fullRequestRefUnsuported   (51},
      fullPolRequestUnsuported   (52),
      inhibitPolMapUnsuported    (53),
      requireExpPolUnsuported    (54),
      ignoreAnyPolUnsuported     (55),
      validityTimeUnsuported     (56) }

  The SCVPStatusCode 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 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
    24 The signature or MAC 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 MAC algorithm
       used by the client to sign the request
    30 The server could not validate the client's signature or MAC
       on the request
    40 The request was previously relayed by the same server
    50 The request contained an unrecognized validation algorithm
    51 The server does not returning the full request in the
       response
    52 The server does not returning the full policy response
    53 The server does not support inhibiting policy mapping
    54 The server does not support requiring explicit policy
    55 The server does not support ignoring the any policy OID
    56 The server only validates requests using current time

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

4.5 requestReference

Malpani, Housley, & Freeman                                    [Page29]
INTERNET DRAFT                   SCVP                      July 2004

  The requestRef allows the SCVP server to identify the request that
  corresponds to this response.  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       [1] HashValue, -- hash of CVRequest
      fullRequest       [2] CVRequest }

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

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

Malpani, Housley, & Freeman                                    [Page30]
INTERNET DRAFT                   SCVP                      July 2004

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

4.5.2 fullRequest

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

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

4.6 Requestor

  The OPTIONAL requestor item is used to identify the requestor.  The
  value is only of local significance to the requestor.  If the SCVP
  client includes a requestor value in the request, then the SCVP
  server MUST return the same value if the server is generating a
  specific response.

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

4.7 responder

  The OPTIONAL responder item is used to identify the server.  The
  value chosen is only of local significance to the SCVP server.  The
  responder items MUST be included if the request included a
  requestor item.

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

  The replyObjects item returns requested objects to the SCVP client,
  each of which tells the client about a single certificate from the
  request.  The replyObjects item MUST be present in the response,
  unless the response is reporting an error.  The CertReply item MUST
  contain cert, replyStatus, replyValTime, replyChecks, replyWantBack,
  and valPolicy items; and the CertReply item MAY contain the
  nextUpdate and certReplyExtensions optional items.

  A non-error response MUST contain one CertReply for each Query item
  in the request.  The order is important.  The first CertReply in
  the sequence MUST correspond to the first Query item in the
  request; the second CertReply in the sequence MUST correspond to
  the second Query item in the request; and so on.
Malpani, Housley, & Freeman                                    [Page31]
INTERNET DRAFT                   SCVP                      July 2004


  The checks item in the request determines the content of the
  replyChecks item in the response.  The wantBack item in the request
  determines the content of the replyWantBacks item in the response.
  The queryExtensions items in the request controls the absence or
  the presence and content of the certReplyExtensions item in the
  response.

  The replyObjects item uses the ReplyObjects type, which has the
  following syntax:

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

    CertReply ::= SEQUENCE {
      cert                       CertReference,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      valAlg                     ValidationAlg,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

4.8.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.8.2 replyStatus

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

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

    ReplyStatus ::= ENUMERATED {
        success                  (0),
        unrecognizedCheck        (1),
        unrecognizedWantBack     (2),
        malformedPKC             (3),
        malformedAC              (4),
        unrecognizedCertPolicy   (5),
        unrecognizedValPolicy    (6),
Malpani, Housley, & Freeman                                    [Page32]
INTERNET DRAFT                   SCVP                      July 2004

        unrecognizedExtension    (7),
        unavailableValidityTime  (8),
        referenceCertHashFail    (9),
        certPathConstructFail   (10),
        certPathNotValid        (11),
        certPathNotValidNow     (12) }

  The meaning of the various ReplyStatus values are:

    0  Success: a definitive answer follows
    1  Failure: an OID in the check item is not recognized
    2  Failure: an OID in the wantBack item is not recognized
    3  Failure: the public key certificate was malformed
    4  Failure: the attribute certificate was malformed
    5  Failure: the certificate policy OID is not recognized
    6  Failure: the validation policy OID is not recognized
    7  Failure: the extension OID is not recognized
    8  Failure: historical data for the requested validity time is
       not available
    9  Failure: the referenced certificate did not match the hash
       value provided
    10 Failure: no certification path could be constructed
    11 Failure: the constructed certification path is invalid
    12 Failure: the constructed certification path is invalid, but
       a query at a later time may be successful

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

4.8.3 replyValTime

  The replyValTime item tells the time at which the information in
  the CertReply was correct.  The replyValTime item represents the
  date and time in UTC, using GeneralizedTime type.  The encoding
  rules for GeneralizedTime in section 3.2.13 MUST be used.

  Within the request, the optional validityTime item tells the date
  and time relative to which the SCVP client wants the server to
  perform the checks.  If the validityTime is not present, the server
  MUST respond as if the client provided the date and time at which
  the server processes the request.

  The information in the CertReply item MUST be formatted as if the
  server created this portion of response at the time indicated in
  the validityTime item of the query.  However, if the server does
  not have appropriate historical information, the server MAY either
  return an error or return information for a later time.

4.8.4 replyChecks

Malpani, Housley, & Freeman                                    [Page33]
INTERNET DRAFT                   SCVP                      July 2004

  The replyChecks contains the responses to the checks item in the
  query.  The replyChecks item repeats the object identifier (OID)
  from the query and an integer.  The value of the integer indicates
  whether the requested check was successful.  The OIDs in the checks
  item of the query are used to identify the corresponding
  replyChecks values.  The OIDs in the replyChecks item MUST match
  the OIDs in the checks item in the request.

  The replyChecks item uses the ReplyChecks type, which has the
  following syntax:

    ReplyChecks ::= SEQUENCE OF ReplyCheck

    ReplyCheck ::= SEQUENCE {
      check                      OBJECT IDENTIFIER,
      status                     INTEGER }

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

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

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

      0: Valid
      1: Not valid

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

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

  The status value for AC issuer certification path building to a
  trusted root, { id-stc 4 }, can be one of the following:

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

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

      0: Valid
      1: Not valid
Malpani, Housley, & Freeman                                    [Page34]
INTERNET DRAFT                   SCVP                      July 2004


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

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

  The status value for revocation status checking of an AC as well as
  AC issuer certification path building to a trusted root along with
  complete status checking, { id-stc 7 }, can be one of the
  following:

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

4.8.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 section 3.2.7.

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

  The octet string value for the public key certificate status, { id-
  swb 3 }, contains an ASN.1 BOOLEAN type.  The value will be TRUE if
Malpani, Housley, & Freeman                                    [Page35]
INTERNET DRAFT                   SCVP                      July 2004

  the certificate is valid, and the value will be FALSE if the
  certificate is not valid.

  The octet string value for the public key information, { id-swb 4 },
  contains the SubjectPublicKeyInfo type.  The syntax and semantics
  of the SubjectPublicKeyInfo type are described in [PKIX-1].

  The octet string value for the AC issuer certification path used to
  verify the certificate in the request, { id-swb 5 }, contains the
  CertBundle type.  The syntax and semantics of the CertBundle type
  are described in section 3.2.7.

  The octet string value for the proof of revocation status of the AC
  issuer certification path, { id-swb 6 }, contains the
  RevocationInfo type.  The syntax and semantics of the
  RevocationInfo type are described in section 3.2.9.

  The octet string value for the proof of revocation status of the
  attribute certificate, { id-swb 7 }, contains the RevocationInfo
  type.  The syntax and semantics of the RevocationInfo type are
  described in section 3.2.9.

  The octet string value for the attribute certificate status, { id-
  swb 8 }, contains an ASN.1 BOOLEAN type.  The value will be TRUE if
  the certificate is valid, and the value will be FALSE if the
  certificate is not valid.

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

4.8.7 nextUpdate

  The nextUpdate item tells the time at which the server expects a
  refresh of information regarding the validity of the certificate to
  become available.  The nextUpdate is especially interesting if the
  certificate revocation status information is not available or the
  certificate is suspended.  The nextUpdate item represents the date
  and time in UTC, using the GeneralizedTime type.  The encoding
  rules for GeneralizedTime in section 3.2.13 MUST be used.

4.8.8 certReplyExtensions

  The certReplyExtensions contains the responses to the
  queryExtension item in the request.  The singleReplyExtensions item
  uses the Extensions type defined in [PKIX-1].  The object
Malpani, Housley, & Freeman                                    [Page36]
INTERNET DRAFT                   SCVP                      July 2004

  identifiers (OIDs) in the queryExtension item in the request are
  used to identify the corresponding reply value.  The
  certReplyExtensions item, when present, contains a sequence of
  Extension items, each of which contains an extnID item, a critical
  item, and an extnValue item.

  The extnID item is an identifier for the extension.  It contains
  the OID that names the extension, and it MUST match one of the OIDs
  in the queryExtension item in the request.

  The critical item is a BOOLEAN, and it MUST be set to FALSE.
  The extnValue item contains an OCTET STRING.  Within the OCTET
  STRING is the extension value.  An ASN.1 type is specified for each
  extension, and identified by extnID.

4.9 requestNonce

  The requestNonce optional item contains an identifier generated by
  the client for the request.  If the client includes a requestNonce
  value in the request and the server is generating a specific
  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 value.

  The requestNonce item uses the octet string type.

4.10 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.2.4 contains information about the client usage of this
  item.

  The context information is opaque to the client, but it provides
  information to the server that ensures that a different
  certification path will be returned (if another one can be found).
  The context information could indicate state on the server or it
  could contain a sequence of hashes of certification paths that have
  already returned to the client.  The protocol does not dictate any
  structure or requirements for this item.  However, implementers
  should review the Security Considerations section of this document
  before selecting a structure.

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

4.11 valPolResponse

Malpani, Housley, & Freeman                                    [Page37]
INTERNET DRAFT                   SCVP                      July 2004

  The valPolResponse contains the resultant full validation policy by
  value used by the server to validate the request. It is the union
  of the

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

  ValPolicy ::=SEQUENCE  {

     validationAlg            ValidationAlg,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [5] TrustAnchors,
     keyUsage             [6] KeyUsage OPTIONAL,
     extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}


4.12 respExtensions

  The respExtensions item MAY contain Extensions.  If present, each
  Extension in the sequence extends the request.  This specification
  does not define any extensions, the facility is provided to allow
  future specifications to extend the SCVP.  The syntax for
  Extensions is imported from [PKIX-1].  The respExtensions item,
  when present, contains a sequence of Extension items, each of which
  contains an extnID item, a critical item, and an extnValue item.

  The extnID item is an identifier for the extension.  It contains
  the object identifier (OID) that names the extension.
  The critical item is a BOOLEAN.  Each extension is designated as
  either critical (with a value of TRUE) or non-critical (with a
  value of FALSE).  An SCVP client MUST reject the response if it
  encounters a critical extension it does not recognize; however, a
  non-critical extension MAY be ignored if it is not recognized.

  The extnValue item contains an OCTET STRING.  Within the OCTET
  STRING is the extension value.  An ASN.1 type is specified for each
  extension, and identified by extnID.

4.13 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

Malpani, Housley, & Freeman                                    [Page38]
INTERNET DRAFT                   SCVP                      July 2004

4.13.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 server(s). It is a implementation decision how
  the keys are stored. This can be accomplished by cryptographic
  hashes of public keys used to sign signedData responses. It could
  also be shared symmetric keys used to HMAC authenticatedData
  responses.

  Simple key validation MUST be used by SCVP clients who cannot
  validate PKIX-1 certificates and are therefore making delegated
  path validation requests to the SCVP server. 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
  for other reasons.


4.13.2 SCVP Server Certificate Validation

  When validating SCVP server certificates using this method, SCVP
  clients MUST use the validation algorithm defined in section 6 of
  PKIX-1.validation. It is a matter of local policy what values to
  use as inputs for the validation algorithm

  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 Policies Request

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

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

    ContentInfo {
Malpani, Housley, & Freeman                                    [Page39]
INTERNET DRAFT                   SCVP                      July 2004

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

  The PolRequest type has the following syntax:

    PolRequest ::= SEQUENCE {
      scvpVersion                INTEGER }

  The scvpVersion item is described in section 3.1.

  SCVP clients SHOULD support validation policy requests. SCVP
  servers MUST support SCVP requests.

6 Validation Policies Response

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

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

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

  The PolResponse type has the following syntax:

    PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      DefaultPolicyID            INTEGER,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime,
      trustAnchors               TrustAnchors,
      validationPolices          SEQUENCE OF ValidationPolRef,
      validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
      authPolicies               SEQUENCE OF AuthPolicy,
      responseTypes              ResponseTypes,
      defaultValPol              ValPolicy,
      clockSkew                  INTEGER OPTIONAL,
      authDataCert               Certificate OPTIONAL }

  ResponseTypes  ::= ENUMERATED {
      cached only                    (0),
Malpani, Housley, & Freeman                                    [Page40]
INTERNET DRAFT                   SCVP                      July 2004

      unique signed only             (1),
      both cached and unique signed  (2)}


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

6.1 scvpVersion

  The scvpVersion item is described in section 3.1.

6.2 PolicyID

  An integer which uniquely represents the version of the default
  validation policy as represented by the trustAnchors, validationAlg,
  authPolicies, clock skew and authDataCerts. If any of these values
  change, the server MUST create a new PolResponse with a new
  PolicyID. If the policy and therefore the policyID has not changed,
  then the server may reused PolicyID 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 select another unique value.

6.3 thisUpdate

  This field indicates the signing date & time of this policy
  response. Since the polResponse is not bound to a specific request.
  A SCVP server may periodically generate the response and use the
  same polResponse for multiple requests.

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

6.4 nextUpdate

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

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

6.5 trustAnchors

  The trustAnchors item specifies the default trust anchors that the
  SCVP server will use if the client directly or indirectly omits the
  trustAnchours from the request.

6.6 validationAlgs

Malpani, Housley, & Freeman                                    [Page41]
INTERNET DRAFT                   SCVP                      July 2004

  The validationAlgs item contains a sequence of object identifiers
  (OIDs).  Each OID identifies a single validation algorithm
  supported by the server.

6.7 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 represents a human
  readable definition of the policy. The list of policies is intended
  to document to the client I authentication is required for some
  requests and if so how.

  AuthPolicy ::= CHOICE {
      AuthPolRefByOID     [0] OBJECT IDENTIFIER,
      AuthPolRefByURI     [1] IA5String}

6.8 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.9 clockSkew

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

6.10 defaultValPolicy

  This is the default validation policy used by the server. A client
  can override these default values by reference using the
  validationPolRef or by value by including then in the request.

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
Malpani, Housley, & Freeman                                    [Page42]
INTERNET DRAFT                   SCVP                      July 2004

  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 identifier of the SCVP server.

  When an SVCP server receives a request that contains a requestor
  item, the server MUST check for its own identifier.  The identifier
  could be located at the beginning of the octet string followed by a
  zero octet, or it could be located between two zero octets.  If the
  server discovers its own identifier in the requestor item, it MUST
  respond with an error, setting the responseStatus to 40.

8 SCVP ASN.1 Module

  This section defines the syntax for SCVP request-response pairs.
  The semantics for the messages are defined in sections 3, 4, 5, and
  6.  The SCVP ASN.1 module follows.

  SCVP

  { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) 21 }

  DEFINITIONS IMPLICIT TAGS ::= BEGIN

  IMPORTS

    AlgorithmIdentifier, Certificate, Extensions, GeneralNames,
    SubjectPublicKeyInfo, UTF8String, CertificateList
      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)
Malpani, Housley, & Freeman                                    [Page43]
INTERNET DRAFT                   SCVP                      July 2004

        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 {
      scvpVersion           INTEGER,
      query                 Query,
      requestor         [0] OCTET STRING OPTIONAL,
      requestNonce      [1] OCTET STRING OPTIONAL,
      reqExtensions     [2] Extensions OPTIONAL }

  Query ::= SEQUENCE {
      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
      checks                  CertChecks,
      wantBack                WantBack,
      valalidationAlg         ValidationAlg,
      requestRefHash          BOOLEAN DEFAULT TRUE,
      fullPolResponse    [0]  BOOLEAN DEFAULT FALSE,
      inhibitPolMap      [1]  BOOLEAN DEFAULT FALSE,
      requireExplicitPol [2]  BOOLEAN DEFAULT FALSE,
      ignoreAnyPol       [3]  BOOLEAN DEFAULT FALSE,
      isCA               [4]  BOOLEAN DEFAULT FALSE,
      signResponse       [5]  BOOLEAN DEFAULT TRUE,
      serverContextInfo  [6]  OCTET STRING OPTIONAL,
      validityTime       [7]  GeneralizedTime OPTIONAL,
      trustAnchors       [8]  TrustAnchors OPTIONAL,
      intermediateCerts  [9]  CertBundle OPTIONAL,
      revInfos          [10]  RevocationInfos OPTIONAL,
      keyusage          [11]  KeyUsage OPTIONAL,
      extendedKeyUsage  [12]  ExtKeyUsageSyntax OPTIONAL,
      queryExtensions   [13]  Extensions OPTIONAL
      producedAt        [14]  GeneralizedTime OPTIONAL
      validationPolRef  [15]  ValidationPolRef OPTIONAL}

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

  PKCReference ::= CHOICE {
      cert              [1] Certificate,
      pkcRef            [2] ESSCertID }
Malpani, Housley, & Freeman                                    [Page44]
INTERNET DRAFT                   SCVP                      July 2004


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

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

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

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

  NameValidationAlg ::= SEQUENCE {
      KeyPurposeId      OBJECT IDENTIFIER,
      ValidationName    GeneralNames }

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

  TrustAnchor ::= SEQUENCE {
      anchor                  PKCReference,
      certPolicies        [1] SEQUENCE SIZE (1..MAX) OF
                              OBJECT IDENTIFIER OPTIONAL }
                              -- if absent, use any-policy

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

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

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

  OtherRevInfo ::= SEQUENCE {
      retype         OBJECT IDENTIFIER,
      revalue        ANY DEFINED BY retype }

   -- SCVP Certificate Validation Request

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

  CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
Malpani, Housley, & Freeman                                    [Page45]
INTERNET DRAFT                   SCVP                      July 2004

      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolRef OPTIONAL,
      respExtensions    [8] Extensions OPTIONAL }

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

  SCVPStatusCode ::= 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),
      unrecognisedValidationAlg  (50),
      FullRequestRefUnsuported   (51},
      FullPolRequestUnsuported   (52),
      InhibitPolMapUnsuported    (53),
      RequireExpPolUnsuported    (54),
      IgnoreAnyPolUnsuported     (55),
      validityTimeUnsuported     (56) }


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

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

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

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

Malpani, Housley, & Freeman                                    [Page46]
INTERNET DRAFT                   SCVP                      July 2004

  CertReply ::= SEQUENCE {
      cert                       ReplyCertificate,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      valAlg                     ValidationAlg,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

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


  ReplyStatus ::= ENUMERATED {
      success                  (0),
      unrecognizedCheck        (1),
      unrecognizedWantBack     (2),
      malformedPKC             (3),
      malformedAC              (4),
      unrecognizedCertPolicy   (5),
      unrecognizedValPolicy    (6),
      unrecognizedExtension    (7),
      unavailableValidityTime  (8),
      referenceCertHashFail    (9),
      certPathConstructFail   (10),
      certPathNotValid        (11),
      certPathNotValidNow     (12) }

  ReplyChecks ::= SEQUENCE OF ReplyCheck

  ReplyCheck ::= SEQUENCE {
      check                      OBJECT IDENTIFIER,
      status                     INTEGER }

  ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

  ReplyWantBack::= SEQUENCE {
      wb                         OBJECT IDENTIFIER,
      value                      OCTET STRING }

  ValPolicy ::=SEQUENCE  {
     validationAlg            ValidationAlg,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [5] TrustAnchors,
     keyUsage             [6] KeyUsage OPTIONAL,
     extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}
Malpani, Housley, & Freeman                                    [Page47]
INTERNET DRAFT                   SCVP                      July 2004


   -- SCVP Validation Policies Request

  id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 }

  VPRequest ::= SEQUENCE {
      scvpVersion                INTEGER }

  -- SCVP Validation Policies Response

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

  PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      DefaultPolicyID            INTEGER,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime,
      trustAnchors               TrustAnchors,
      validationPolices          SEQUENCE OF ValidationPolRef,
      validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
      authPolicies               SEQUENCE OF AuthPolicy,
      responseTypes              ResponseTypes,
      defaultValPol              ValPolicy,
      clockSkew                  INTEGER OPTIONAL,
      authDataCert               Certificate OPTIONAL }

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

  -- SCVP Check Identifiers

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

  id-stc-build-pkc-path        OBJECT IDENTIFIER ::= { id-stc 1 }
  id-stc-build-valid-pkc-path  OBJECT IDENTIFIER ::= { id-stc 2 }
  id-stc-build-status-checked-pkc-path
                               OBJECT IDENTIFIER ::= { id-stc 3 }
  id-stc-build-aa-path         OBJECT IDENTIFIER ::= { id-stc 4 }
  id-stc-build-valid-aa-path   OBJECT IDENTIFIER ::= { id-stc 5 }
  id-stc-build-status-checked-aa-path
                               OBJECT IDENTIFIER ::= { id-stc 6 }
  id-stc-status-check-ac-and-build-status-checked-aa-path
                               OBJECT IDENTIFIER ::= { id-stc 7 }

  -- SCVP WantBack Identifiers

  id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
Malpani, Housley, & Freeman                                    [Page48]
INTERNET DRAFT                   SCVP                      July 2004

             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  18 }

  id-swb-pkc-cert-path         OBJECT IDENTIFIER ::= { id-swb 1 }
  id-swb-pkc-revocation-info   OBJECT IDENTIFIER ::= { id-swb 2 }
  id-swb-pkc-cert-status       OBJECT IDENTIFIER ::= { id-swb 3 }
  id-swb-pkc-public-key-info   OBJECT IDENTIFIER ::= { id-swb 4 }
  id-swb-aa-cert-path          OBJECT IDENTIFIER ::= { id-swb 5 }
  id-swb-aa-revocation-info    OBJECT IDENTIFIER ::= { id-swb 6 }
  id-swb-ac-revocation-info    OBJECT IDENTIFIER ::= { id-swb 7 }
  id-swb-ac-cert-status        OBJECT IDENTIFIER ::= { id-swb 8 }
  id-swb-unique-resp-required  OBJECT IDENTIFIER ::= { id-swb 9 }

  -- SCVP Validation Policy Identifiers

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

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

  END

9 Security Considerations

  A client that trusts a server's response for validation of a
  certificate inherently trusts that server as much as it would trust
  its own validation software.  This means that if an attacker
  compromises a trusted SCVP server, the attacker can change the
  validation processing for every client that relies on that server.
  Thus, an SCVP server must be protected at least as well as the
  trust anchors that the SCVP server trusts.

  Clients MUST check the requestRef item in the response and ensure
  that it matches their original request.  Requests contain a lot of
  information that affects the response and clients need to ensure
  that the server response corresponds to the expected request.

  When the SCVP response is used to determine the validity of a
  certificate, the client MUST validate the signature on the response
  to ensure that the expected SCVP server generated it.  If the
  client does not check the signature on the response, a man-in-the-
  middle attack could fool the client into believing modified
  responses from the server, or responses to questions the client did
  not ask.

  If the client does not include a requestNonce item, or if the
  client does not check that the requestNonce in the response matches
  the value in the request, an attacker can replay previous responses
  from the SCVP server.

Malpani, Housley, & Freeman                                    [Page49]
INTERNET DRAFT                   SCVP                      July 2004

  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.

  The request and response for which policies are supported on the
  server are unsigned.  These could lead to a denial of service
  attack where a man-in-the-middle indicates that a server supports a
  different set of validation policies than it actually does.  This
  could result in the client requesting validation based on a policy
  the server does not support or lead the client using a less
  desirable policy.

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

  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 though URIs are technically non-persistent, the use
  of an URI is much more readily understood because of there
  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.

10 References

  Normative and informative references are provided.

10.1  Normative References

  [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

  [CMS]       Housley, R., "Cryptographic Message Syntax", RFC
             2630,June 1999.

  [OCSP]      Myers, M., Ankney, R., Malpani, A., Galperin, S. and
             C. Adams, "X.509 Internet Public Key Infrastructure -
             Online Certificate Status Protocol - OCSP", RFC 2560,
             June 1999.

Malpani, Housley, & Freeman                                    [Page50]
INTERNET DRAFT                   SCVP                      July 2004

  [PKIX-1]     Housley, R., Polk, T, Ford, W.  and Solo, D.,
             "Internet X.509 Public Key Infrastructure Certificate
             and Certificate Revocation List (CRL) Profile", RFC
             3280, April 2002.

  [PKIX-AC]    Farrell, S., and R.  Housley, "An Internet Attribute
             Certificate Profile for Authorization", RFC 3281,
             April 2002.

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

  [SHA-1]     National Institute of Standards and Technology,
             "Secure Hash Standard", NIST FIPS Pub 180-1, April
             1995.

  [UTF8]      Yergeau, F., "UTF-8, a transformation format of ISO
             10646", RFC 2279, January 1998.

  [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME",
             RFC 2634, June 1999.

  [HTTP-TLS]   Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.

10.2  Informative References

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

  [OpenPGP]    Callas, J., Donnerhacke, L., Finney, H., and R.
             Thayer, "OpenPGP Message Format", RFC 2440, November
             1998.

  [RQMTS]     Pinkas, D., and R.  Housley, "Delegated Path
             Validation and Delegated Path Discovery Protocol
             Requirements", RFC 3379, September 2002.

11 Acknowledgments

  The lively debate in the PKIX Working Group has made a significant
  impact on this protocol.  Denis Pinkas and Phillip Hallam-Baker
  suggested additional requirements for the protocol.  Mike Myers
  identified areas that needed clarification.  Frank Balluffi and
  Ameya Talwalkar did an implementation based on an early draft of
  this protocol, and they identified a few deficiencies.  John
  Thielens, Peter Sylvester, and Yuriy Dzambasow provided good input,
  greatly improving this document.
Malpani, Housley, & Freeman                                    [Page51]
INTERNET DRAFT                   SCVP                      July 2004


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

  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
Malpani, Housley, & Freeman                                    [Page52]
INTERNET DRAFT                   SCVP                      July 2004


  Required parameters: format

  Optional parameters: None

  Encoding considerations: binary

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

  Interoperability considerations: None

  Published specification: IETF PKIX Working Group Draft on Simple
  Certificate Validation Protocol (SCVP)

  Applications which use this media type: SCVP servers

  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/cv-policies-request

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

  MIME media type name: application

  MIME subtype name: cv-policies-request

  Required parameters: format

  Optional parameters: None

  Encoding considerations: binary

  Security considerations: Carries a request for information.

  Interoperability considerations: None

Malpani, Housley, & Freeman                                    [Page53]
INTERNET DRAFT                   SCVP                      July 2004

  Published specification: IETF PKIX Working Group Draft on Simple
  Certificate Validation Protocol (SCVP)

  Applications which use this media type: SCVP clients

  Additional information:

      Magic number(s): None
      File extension(s): .SPQ
      Macintosh File Type Code(s): none

  Person & email address to contact for further information:
  Ambarish Malpani <ambarish@malpani.biz>

  Intended usage: COMMON

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

 A.4 application/cv-policies-response

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

  MIME media type name: application

  MIME subtype name: cv-policies-response

  Required parameters: format

  Optional parameters: None

  Encoding considerations: Binary

  Security considerations: None

  Interoperability considerations: None

  Published specification: IETF PKIX Working Group Draft on Simple
  Certificate Validation Protocol (SCVP)

  Applications which use this media type: SCVP servers

  Additional information:
      Magic number(s): None
      File extension(s): .SPP
      Macintosh File Type Code(s): none

  Person & email address to contact for further information:
  Ambarish Malpani <ambarish@malpani.biz>

Malpani, Housley, & Freeman                                    [Page54]
INTERNET DRAFT                   SCVP                      July 2004

  Intended usage: COMMON

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

Appendix B  -- SCVP over HTTP

  This appendix describes the formatting conventions for the SCVP
  request and response when carried by HTTP.

B.1 SCVP Request

  HTTP based SCVP requests can use the POST method to submit their
  requests.  Where privacy is a requirement, SCVP transactions
  exchanged using HTTP MAY be protected using either TLS/SSL or some
  other lower layer protocol.

  An SCVP request using the POST method is constructed as follows:

      The Content-Type header MUST have the value "application/scvp-
      request".

      The Content-Length header MUST be present and have the exact
      length of the request.

      The body of the message is the binary value of the DER encoding
      of the CVRequest.  Other HTTP headers MAY be present and MAY be
      ignored if not understood by the requestor.

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

  B.2 SCVP Response

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

  The Content-Type header MUST have the value "application/scvp-
  response".

  The Content-Length header MUST be present and specify the length of
  the response.

  Other HTTP headers MAY be present and MAY be ignored if not
  understood by the requestor.

Appendix C  -- Author Contact Information

  Ambarish Malpani
  Malpani Consulting Services
Malpani, Housley, & Freeman                                    [Page55]
INTERNET DRAFT                   SCVP                      July 2004

  ambarish@malpani.biz

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

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

  Full Copyright Statement

  Copyright (C) The Internet Society (2002).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain
  it or assist in its implementation may be prepared, copied,
  published and distributed, in whole or in part, without restriction
  of any kind, provided that the above copyright notice and this
  paragraph are included on all such copies and derivative works.
  In addition, the ASN.1 modules presented in Appendices A and B may
  be used in whole or in part without inclusion of the copyright
  notice.   However, this document itself may not be modified in any
  way, such as by removing the copyright notice or references to the
  Internet Society or other Internet organizations, except as needed
  for the purpose of developing Internet standards in which case the
  procedures for copyrights defined in the Internet Standards process
  shall be followed, or as required to translate it into languages
  other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.  This
  document and the information contained herein is provided on an "AS
  IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Malpani, Housley, & Freeman                                    [Page56]


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