[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-11.txt               Malpani Consulting Services
December 2002                                              R. Housley
Expires in six months                                RSA Laboratories
                                                           T. Freeman
                                                       Microsoft Corp

             Simple Certificate Validation Protocol (SCVP)


Status of this memo

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

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

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

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

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

Copyright Notice

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

Abstract

   SCVP allows a client to offload certificate handling to a server. The
   server can 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.








Malpani, Housley, & Freeman                                     [Page 1]

INTERNET DRAFT                    SCVP                     December 2002


Table of Contents

 1 Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1 SCVP overview and requirements  . . . . . . . . . . . . . . .   4
   1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3 Validation Policies . . . . . . . . . . . . . . . . . . . . .   5
 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . .   6
 3 Validation Request  . . . . . . . . . . . . . . . . . . . . . . .   6
   3.1 scvpVersion . . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.2 query . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1 queriedCerts  . . . . . . . . . . . . . . . . . . . . .   9
       3.2.2 checks  . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.3 wantBack  . . . . . . . . . . . . . . . . . . . . . . .  11
       3.2.4 serverContextInfo . . . . . . . . . . . . . . . . . . .  12
       3.2.5 valPolicy . . . . . . . . . . . . . . . . . . . . . . .  13
       3.2.6 validityTime  . . . . . . . . . . . . . . . . . . . . .  14
       3.2.7 trustAnchors  . . . . . . . . . . . . . . . . . . . . .  14
       3.2.8 intermediateCerts . . . . . . . . . . . . . . . . . . .  15
       3.2.9 revInfos  . . . . . . . . . . . . . . . . . . . . . . .  16
       3.2.10 queryExtensions  . . . . . . . . . . . . . . . . . . .  16
   3.3 requestor . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   3.4 requestNonce  . . . . . . . . . . . . . . . . . . . . . . . .  17
   3.5 reqExtensions . . . . . . . . . . . . . . . . . . . . . . . .  17
 4 Validation Response . . . . . . . . . . . . . . . . . . . . . . .  18
   4.1 scvpVersion . . . . . . . . . . . . . . . . . . . . . . . . .  20
   4.2 producedAt  . . . . . . . . . . . . . . . . . . . . . . . . .  20
   4.3 responseStatus  . . . . . . . . . . . . . . . . . . . . . . .  20
   4.4 requestReference  . . . . . . . . . . . . . . . . . . . . . .  22
       4.4.1 requestHash . . . . . . . . . . . . . . . . . . . . . .  22
       4.4.2 fullRequest . . . . . . . . . . . . . . . . . . . . . .  23
   4.5 requestor . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   4.6 responder . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   4.7 replyObjects  . . . . . . . . . . . . . . . . . . . . . . . .  23
       4.7.1 cert  . . . . . . . . . . . . . . . . . . . . . . . . .  24
       4.7.2 replyStatus . . . . . . . . . . . . . . . . . . . . . .  24
       4.7.3 replyValTime  . . . . . . . . . . . . . . . . . . . . .  25
       4.7.4 replyChecks . . . . . . . . . . . . . . . . . . . . . .  26
       4.7.5 replyWantBack . . . . . . . . . . . . . . . . . . . . .  27
       4.7.6 valPolicy . . . . . . . . . . . . . . . . . . . . . . .  29
       4.7.7 nextUpdate  . . . . . . . . . . . . . . . . . . . . . .  29
       4.7.8 certReplyExtensions . . . . . . . . . . . . . . . . . .  29
   4.8 requestNonce  . . . . . . . . . . . . . . . . . . . . . . . .  30
   4.9 serverContextInfo . . . . . . . . . . . . . . . . . . . . . .  30
   4.10 respExtensions . . . . . . . . . . . . . . . . . . . . . . .  30
 5 Validation Policies Request . . . . . . . . . . . . . . . . . . .  31
 6 Validation Policies Response  . . . . . . . . . . . . . . . . . .  31
 7 SCVP Server Relay . . . . . . . . . . . . . . . . . . . . . . . .  32
 8 SCVP ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . .  32



Malpani, Housley, & Freeman                                     [Page 2]

INTERNET DRAFT                    SCVP                     December 2002


 9 Security Considerations . . . . . . . . . . . . . . . . . . . . .  38
10 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  39
   10.1 Normative References . . . . . . . . . . . . . . . . . . . .  39
   10.2 Informative References . . . . . . . . . . . . . . . . . . .  40
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
Appendix A -- MIME Registrations . . . . . . . . . . . . . . . . . .  41
   A.1 application/scvp-request  . . . . . . . . . . . . . . . . . .  41
   A.2 application/scvp-response . . . . . . . . . . . . . . . . . .  42
   A.3 application/scvp-policies-request . . . . . . . . . . . . . .  43
   A.4 application/scvp-policies-response  . . . . . . . . . . . . .  44
Appendix B -- SCVP over HTTP . . . . . . . . . . . . . . . . . . . .  45
   B.1 SCVP Request  . . . . . . . . . . . . . . . . . . . . . . . .  45
   B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . . . .  45
Appendix C -- Author Contact Information . . . . . . . . . . . . . .  46
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  47




































Malpani, Housley, & Freeman                                     [Page 3]

INTERNET DRAFT                    SCVP                     December 2002


1 Introduction

   Certificate validation is complex. If certificate handling is to be
   widely deployed in a variety of applications and environments, the
   amount of processing an application needs to perform before it can
   accept a certificate needs to be reduced. There are a variety of
   applications that can make use of public key certificates, but these
   applications are burdened with the overhead of constructing and
   validating the certification paths. SCVP reduces this overhead for
   two classes of certificate-using applications.

   The first class of application wants just two things. First, they
   want confirmation that the public key belongs to the identity named
   in the certificate. Second, they want to know if the public key can
   be used for the intended purpose. The client delegates certificate
   validation to the SCVP server.

   The second class of application can perform certification path
   validation, but these applications have no reliable method of
   constructing a certification path to a trust anchor. The client
   delegates certification path construction to the SCVP server.

1.1 SCVP overview and requirements

   The SCVP meets the requirements documented in [RQMTS].

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

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

   Trusted SCVP servers can perform certification path construction and
   validation for the client. For a client uses these services, the
   client inherently trusts the SCVP server as much as it would its own
   path validation software (if it contained such software). There are



Malpani, Housley, & Freeman                                     [Page 4]

INTERNET DRAFT                    SCVP                     December 2002


   two main reasons that a client may want to trust such an SCVP server:

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

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

1.2 Terminology

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

1.3 Validation Policies

   A validation policy can be used to specify the SCVP configuration.
   The validation policy is determined by private agreement between the
   client and the server, but it MUST be represented as an OBJECT
   IDENTIFIER. The SCVP server can assign identifiers that indicate that
   some settings are used in addition to values provided in the SCVP
   request. These values might include certificate policies and trust
   anchors.

   In a separate, yet to be written, document application-specific
   validation policies will be defined. These validation policies should
   serve as guides for the development of further application-specific
   validation policies. S/MIME, IPsec, and TLS likely candidate
   applications for this document.

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

   Revocation checking is one aspect of certification path validation
   defined in [PKIX-1]. Therefore, the validation policy MUST specify
   the source of revocation information. Five alternatives are
   envisioned:

      1.  full CRLs (or full Authority Revocation Lists) have to be
          collected;

      2.  OCSP responses, using [OCSP], have to be collected;




Malpani, Housley, & Freeman                                     [Page 5]

INTERNET DRAFT                    SCVP                     December 2002


      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, but it can also
   be used with email. Appendix A and Appendix B provide the details
   necessary to use SCVP with HTTP.

   SCVP includes two request-response pairs. The primary request-
   response pair handles certificate validation. The secondary request-
   response pair is used to determine the list of validation policies
   supported by a specific SCVP server.

   Section 3 defines the certificate validation request, and section 4
   defines the corresponding response.

   Section 5 defines the validation policies request, and section 6
   defines the corresponding response.

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

3 Validation Request

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

   There are two forms of SCVP request: unsigned and signed. A signed
   request can be used to authenticate the client to the server. A
   server MAY require all requests to be signed, and a server MAY
   discard all unsigned requests. Alternatively, a server MAY choose to
   process unsigned requests.









Malpani, Housley, & Freeman                                     [Page 6]

INTERNET DRAFT                    SCVP                     December 2002


   The unsigned request consists of a certValRequest encapsulated in a
   ContentInfo.  An overview of this structure is provided below.  Many
   details are not shown, but the way that SCVP makes use of CMS is
   clearly illustrated.

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

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

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

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

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

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

   The syntaxes for SignedData and ContentInfo are defined in [CMS]. The
   syntax for CVRequest is defined below. The CVRequest item contains
   the client request. The CVRequest item contains the scvpVersion and
   query items; and the CVRequest item MAY also contain the requestor,
   requestNonce, and reqExtensions items.




Malpani, Housley, & Freeman                                     [Page 7]

INTERNET DRAFT                    SCVP                     December 2002


   The CVRequest MUST have the following syntax:

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

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

3.1 scvpVersion

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

3.2 query

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

   Query MUST have the following syntax:

      Query ::= SEQUENCE {
        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference,
        checks                CertChecks,
        wantBack              WantBack,
        serverContextInfo [0] OCTET STRING OPTIONAL,
        valPolicy         [1] ValidationPolicy OPTIONAL,
        validityTime      [2] GeneralizedTime OPTIONAL,
        trustAnchors      [3] TrustAnchors OPTIONAL,
        intermediateCerts [4] CertBundle OPTIONAL,
        revInfos          [5] RevocationInfos OPTIONAL,
        queryExtensions   [6] Extensions OPTIONAL }

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



Malpani, Housley, & Freeman                                     [Page 8]

INTERNET DRAFT                    SCVP                     December 2002


   provide context for the client request. The OPTIONAL queryExtensions
   item provides for future expansion of the query syntax.

3.2.1 queriedCerts

   The queriedCerts item, using the CertReference type, identifies the
   certificate that is the object of the request. The certificate is
   either a public key certificate or an attribute certificate. The
   certificate is either directly included or it is referenced. When
   referenced, a SHA-1 hash value of the referenced item is included to
   ensure that the SCVP client and the SCVP server both obtain the same
   certificate when the referenced certificate is fetched. Certificate
   references use the ESSCertID type defined in [ESS]. CertReference has
   the following syntax:

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

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

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

   The ASN.1 definition of Certificate is imported from [PKIX-1]; the
   definition of AttributeCertificate is imported from [PKIX-AC]; and
   the definition of ESSCertID is imported from [ESS].

3.2.2 checks

   The checks item describes the checking that the SCVP client wants the
   SCVP server to perform on the certificate(s) in the queriedCerts
   item. The checks item MUST contain a sequence of object identifiers.
   Each object identifier tells the SCVP server what checking the client
   expects the server to perform. For each check specified in the
   request, the SCVP server MUST perform all of the requested checks, or
   return an error.

   Revocation status checking inherently includes path construction.
   Also, building a validated certification path does not imply
   revocation status checks (although a server may still choose to
   perform revocation status checks).






Malpani, Housley, & Freeman                                     [Page 9]

INTERNET DRAFT                    SCVP                     December 2002


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

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

   A list of object identifiers (OIDs) indicates the checking that the
   client wants the SCVP server to perform on the certificate(s) in the
   queriedCerts item.

   For public key certificates, OIDs are defined for the following
   checks:

      - Build a certification path to a trusted root;

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

      - Do revocation status checks on the certification path.

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

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

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

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

      - Do revocation status checks on the AC as well as the
        certification path for the AC issuer.

   For these purposes, the following OIDs are defined:

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

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




Malpani, Housley, & Freeman                                    [Page 10]

INTERNET DRAFT                    SCVP                     December 2002


3.2.3 wantBack

   The wantBack item describes the kind of information the SCVP client
   wants from the SCVP server for the certificate(s) in the queriedCerts
   item. The wantBack item MUST contain a sequence of object
   identifiers. Each object identifier tells the SCVP server what the
   client wants to know about the queriedCerts item. For each type of
   information specified in the request, the server MUST return
   information regarding its finding (in a successful response).

   For example, a request might include a checks item that only
   specifies certification path building and include a wantBack item
   that requests the return of the certification path built by the
   server. In this case, the response would not include a status for the
   validation of the certification path, but it would include a
   certification path that the server considers to be valid. A client
   that wants to perform its own certification path validation might use
   a request of this form.

   Alternatively, a request might include a checks item that requests
   the server to build a certification path and validate it, including
   revocation checking, and include a wantBack item that requests the
   return of the status. In this case, the response would include only a
   status for the validation of the certification path. A client that
   completely delegates certification path validation might use a
   request of this form.

   The wantBack item uses the WantBack type, which has the following
   syntax:

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

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

      - Certification path built for the certificate;

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

      - Status indication; and

      - Public key from the certificate.








Malpani, Housley, & Freeman                                    [Page 11]

INTERNET DRAFT                    SCVP                     December 2002


   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 ::= { id-pkix 18 }  -- SCVP want back

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

3.2.4 serverContextInfo

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

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









Malpani, Housley, & Freeman                                    [Page 12]

INTERNET DRAFT                    SCVP                     December 2002


   change any items other than:

      - requestNonce;

      - serverContextInfo; and

      - the client's signature on the request

3.2.5 valPolicy

   The valPolicy item, when present, defines the validation policy to be
   used by the SCVP server during certificate validation. The client can
   use this option instead of specifying other SCVP configuration items
   such as trustAnchors. The value of this item is determined by private
   agreement between the client and the server, but it MUST be
   represented as an object identifier. The server might want to assign
   identifiers that indicate that some settings are used in addition to
   others given in the request. In this way, the validation policy
   object identifier can be a shorthand for some SCVP options, but not
   others.

   The valPolicy item uses the ValidationPolicy type, which has the
   following syntax:

      ValidationPolicy ::= SEQUENCE {
        valPolicyId           OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valPolicyId OPTIONAL }

   If no validation policy is specified in the request, then the SCVP
   server's default validation policy is used. The default validation
   policy may also be explicitly specified. The object identifier to
   identify the default validation policy is:

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

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













Malpani, Housley, & Freeman                                    [Page 13]

INTERNET DRAFT                    SCVP                     December 2002


   The meaning of the default validation policy is:

      - Trust anchors will come from the trustAnchors item. If no
        certificates are specified in the trustAnchors item, then
        the SCVP server will use trust anchors of its own choosing.

      - The acceptable policy set will come from the certPolicies
        item associated with the selected trust anchor. If no
        certificate policies are specified in the certPolicies item,
        then the SCVP server will use any-policy.

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

3.2.6 validityTime

   The OPTIONAL validityTime item tells the date and time relative to
   which the SCVP client wants the server to perform the checks. If the
   validityTime is present, it MUST be encoded as GeneralizedTime. If
   the validityTime is not present, the server MUST respond as if the
   client provided the date and time at which the server processes the
   request.

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

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

3.2.7 trustAnchors

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

   The TrustAnchors type contains one or more trust anchor
   specification. A certificate reference can be used to identify the
   trust anchor distinguished name, public key algorithm, associated
   public key parameters, if needed, and the trusted public key.
   Alternatively, these items can be provided directly. The order of
   trust anchor specifications within the sequence is not important.



Malpani, Housley, & Freeman                                    [Page 14]

INTERNET DRAFT                    SCVP                     December 2002


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

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

   TrustAnchors has the following syntax:

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

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

      TrustAnchorInfo ::= CHOICE {
        certRef                 PKCReference,
        rawInfo             [3] RawTrustAnchorInfo }

      RawTrustAnchorInfo ::= SEQUENCE {
        name                    Name,
        algorithm               AlgorithmIdentifier,
        pubKey                  BIT STRING }

3.2.8 intermediateCerts

   The OPTIONAL intermediateCerts item helps the SCVP server create
   valid certification paths. The intermediateCerts item, when present,
   provides certificates that the server MAY use when forming a
   certification path. The certificates in the intermediateCerts item
   MAY be used by the server in addition to any other certificates that
   the server can access when building certification paths. The
   intermediateCerts item, when present, MUST contain at least one
   certificate. The intermediateCerts item MUST be structured as a
   CertBundle. The certificates in the intermediateCerts MUST NOT be
   trusted by the server just because they are present in this item.

   The CertBundle type contains one or more certificate references. The
   order of the entries in the bundle is not important. CertBundle has
   the following syntax:

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






Malpani, Housley, & Freeman                                    [Page 15]

INTERNET DRAFT                    SCVP                     December 2002


3.2.9 revInfos

   The OPTIONAL revInfo item specifies revocation information such as
   CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP
   server MAY use when validating certification paths. The purpose of
   the revInfos item is to provide revocation information to which the
   server might not otherwise have access (for example, an OCSP response
   that the client received along with the certificate). Note that the
   information in the revInfos item might not be used by the server. For
   example, the revocation information might be associated with
   certificates that the server does not use in certification path
   building.

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

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

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

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

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

   The riType object identifiers are as follows:

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

      id-ri-crl                    OBJECT IDENTIFIER ::= { id-ri 1 }
      id-ri-ocsp-response          OBJECT IDENTIFIER ::= { id-ri 2 }
      id-ri-delta-crl              OBJECT IDENTIFIER ::= { id-ri 3 }

3.2.10 queryExtensions

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



Malpani, Housley, & Freeman                                    [Page 16]

INTERNET DRAFT                    SCVP                     December 2002


   contain extnID, critical, and extnValue items.

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

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

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

3.3 requestor

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

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

3.4 requestNonce

   The OPTIONAL requestNonce item contains an identifier generated by
   the SCVP client for the request. If the client includes a
   requestNonce value in the request, then the server MUST return the
   same value in the response. The client SHOULD include a requestNonce
   item in every request to prevent an attacker from acting as a man-in-
   the-middle by replaying old responses from the server. The
   requestNonce value SHOULD change with every request sent by the
   client.

   The requestNonce item MUST be an octet string.

3.5 reqExtensions

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



Malpani, Housley, & Freeman                                    [Page 17]

INTERNET DRAFT                    SCVP                     December 2002


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

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

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

4 Validation Response

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

   There are two forms of an SCVP response: unsigned and signed. An
   unsigned response MUST only be generated for an error status. An
   overview of the structure used for an unsigned response is provided
   below. Many details are not shown, but the way that SCVP makes use of
   CMS is clearly illustrated.

      ContentInfo {
        contentType        id-ct-scvp-certValResponse,
                                    -- (1.2.840.113549.1.9.16.1.11)
        content            CVResponse }

   The signed response consists of a CVResponse encapsulated in a
   SignedData which is in turn encapsulated in a ContentInfo. An
   overview of the structure used for a signed response is provided
   below. Again, many details are not shown, but the way that SCVP makes
   use of CMS is clearly illustrated.

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

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




Malpani, Housley, & Freeman                                    [Page 18]

INTERNET DRAFT                    SCVP                     December 2002


      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

   The SCVP server MUST include its own certificate in the certificates
   field within SignedData. Other certificates can also be included. The
   SCVP server MAY also provide one or more CRLs in the crls field
   within SignedData.

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

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

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










Malpani, Housley, & Freeman                                    [Page 19]

INTERNET DRAFT                    SCVP                     December 2002


   The CVResponse MUST have the following syntax:

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

4.1 scvpVersion

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

4.2 producedAt

   The producedAt item tells the date and time at which the SCVP server
   generated the response. The producedAt item represents the date and
   time in UTC, using the GeneralizedTime type.

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

4.3 responseStatus

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

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









Malpani, Housley, & Freeman                                    [Page 20]

INTERNET DRAFT                    SCVP                     December 2002


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

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

      SCVPStatusCode ::= ENUMERATED {
        okay                    (0),
        skipUnrecognizedItems   (1),
        tooBusy                (10),
        badStructure           (20),
        unsupportedVersion     (21),
        abortUnrecognizedItems (22),
        unrecognizedSigKey     (23),
        badSignature           (24),
        unableToDecode         (25),
        notAuthorized          (26),
        unsupportedChecks      (27),
        unsupportedWantBacks   (28),
        unsupportedSignature   (29),
        invalidSignature       (30),
        relayingLoop           (40) }

   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
      20  The structure of the request was wrong
      21  The version of request is not supported by this server
      22  The request included unrecognized items, and the server
            was not able to continue processing
      23  The key given in the RequestSignature is not recognized
      24  The signature did not match the body of the request
      25  The encoding was not understood
      26  The request was not authorized
      27  The request included unsupported checks items, and the
            server was not able to continue processing
      28  The request included unsupported want back items, and
            the server was not able to continue processing
      29  The server does not support the signature algorithm
            used by the client to sign the request
      30  The server could not validate the client's signature
            on the request
      40  The request was previously relayed by the same server




Malpani, Housley, & Freeman                                    [Page 21]

INTERNET DRAFT                    SCVP                     December 2002


4.4 requestReference

   The requestRef allows the SCVP server to identify the request that
   corresponds to this response. It associates the response to a
   particular request using a hash of the request or a copy of CVRequest
   from the request.

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

   When using connectionless protocols, the requestRef item allows the
   client to associate a response with a request. However, the
   requestNonce provides a better mechanism for matching requests and
   responses. When the fullRequest alternative is used, the response
   provides a single data structure that is suitable for archive of the
   transaction.

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

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

4.4.1 requestHash

   The requestHash item is the hash of the CVRequest. By default, SHA-1
   is used as the one-way hash function, but others can be used.  The
   requestHash item serves two purposes. First, it allows a client to
   determine that the request was not maliciously modified. Second, it
   allows the client to associate a response with a request when using
   connectionless protocols. However, the requestNonce provides a better
   mechanism for matching requests and responses.

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

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

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

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




Malpani, Housley, & Freeman                                    [Page 22]

INTERNET DRAFT                    SCVP                     December 2002


4.4.2 fullRequest

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

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

4.5 requestor

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

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

4.6 responder

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

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

4.7 replyObjects

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

   A non-error response MUST contain one CertReply for each Query item
   in the request. The order is important. The first CertReply in the
   sequence MUST correspond to the first Query item in the request; the
   second CertReply in the sequence MUST correspond to the second Query
   item in the request; and so on.




Malpani, Housley, & Freeman                                    [Page 23]

INTERNET DRAFT                    SCVP                     December 2002


   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                       ReplyCertificate,
        replyStatus                ReplyStatus,
        replyValTime               GeneralizedTime,
        replyChecks                ReplyChecks,
        replyWantBacks             ReplyWantBacks,
        valPolicy                  ValidationPolicy,
        nextUpdate             [1] GeneralizedTime OPTIONAL,
        certReplyExtensions    [2] Extensions OPTIONAL }

4.7.1 cert

   The cert item contains either the public key certificate or the
   attribute certificate about which the client is requesting
   information.

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

   The ASN.1 definition of Certificate is imported from [PKIX-1]; and
   the definition of AttributeCertificate is imported from [PKIX-AC].

4.7.2 replyStatus

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










Malpani, Housley, & Freeman                                    [Page 24]

INTERNET DRAFT                    SCVP                     December 2002


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

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


   The meaning of the various ReplyStatus values are:

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

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

4.7.3 replyValTime

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



Malpani, Housley, & Freeman                                    [Page 25]

INTERNET DRAFT                    SCVP                     December 2002


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

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

4.7.4 replyChecks

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

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

      ReplyChecks ::= SEQUENCE OF ReplyCheck

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

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

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

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

      0: Valid
      1: Not valid








Malpani, Housley, & Freeman                                    [Page 26]

INTERNET DRAFT                    SCVP                     December 2002


   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

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

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

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

      0: Valid
      1: Not valid

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

      0: Good
      1: Revoked
      2: Unknown

   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

4.7.5 replyWantBack

   The replyWantBack contains the responses to the wantBack item in the
   request. The replyWantBack item includes the object identifier (OID)
   from the wantBack item in the request and an octet string. Within the
   octet string is the requested value. The OIDs in the wantBack item in
   the request are used to identify the corresponding reply value. The
   OIDs in the replyWantBack item MUST match the OIDs in the wantBack
   item in the request.





Malpani, Housley, & Freeman                                    [Page 27]

INTERNET DRAFT                    SCVP                     December 2002


   The replyWantBack item uses the ReplyWantBack type, which has the
   following syntax:

      ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

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

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

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

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

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

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

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

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

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





Malpani, Housley, & Freeman                                    [Page 28]

INTERNET DRAFT                    SCVP                     December 2002


4.7.6 valPolicy

   The valPolicy item tells the validation policy used by the SCVP
   server. Even if the query does not include a validation policy, the
   server MUST indicate the validation policy that was used. The
   valPolicy value MUST NOT be id-svp-defaultValPolicy.

   The syntax and semantics of the valPolicy item are descried in
   section 3.2.5.

4.7.7 nextUpdate

   The nextUpdate item tells the time at which the server expects
   additional information regarding the validity of the certificate to
   become available. Such information could change the status of the
   certificate; however, it might not change the status of the
   certificate. The nextUpdate is especially interesting if the
   certificate revocation status information is not available or the
   certificate is suspended. The nextUpdate item represents the date and
   time in UTC, using the GeneralizedTime type. The encoding rules for
   GeneralizedTime in section 4.2 MUST be used.

4.7.8 certReplyExtensions

   The certReplyExtensions contains the responses to the queryExtension
   item in the request. The singleReplyExtensions item uses the
   Extensions type defined in [PKIX-1]. The object identifiers (OIDs) in
   the queryExtension item in the request are used to identify the
   corresponding reply value. The certReplyExtensions item, when
   present, contains a sequence of Extension items, each of which
   contains an extnID item, a critical item, and an extnValue item.

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

   The critical item is a BOOLEAN, and it MUST be set to FALSE.

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










Malpani, Housley, & Freeman                                    [Page 29]

INTERNET DRAFT                    SCVP                     December 2002


4.8 requestNonce

   The requestNonce optional item contains an identifier generated by
   the client for the request. If the client includes a requestNonce
   value in the request, then the server MUST return the same value in
   the response.

   The requestNonce item uses the octet string type.

4.9 serverContextInfo

   The serverContextInfo item in a response is a mechanism for the
   server to pass some opaque context information to the client. If the
   client does not like the certification path retuned, it can make a
   new query and pass along this context information.

   Section 3.2.4 contains information about the client usage of this
   item.

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

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

4.10 respExtensions

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

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

   The critical item is a BOOLEAN. Each extension is designated as
   either critical (with a value of TRUE) or non-critical (with a value
   of FALSE). An SCVP client MUST reject the response if it encounters a



Malpani, Housley, & Freeman                                    [Page 30]

INTERNET DRAFT                    SCVP                     December 2002


   critical extension it does not recognize; however, a non-critical
   extension MAY be ignored if it is not recognized.

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

5 Validation Policies Request

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

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

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

   The VPRequest type has the following syntax:

      VPRequest ::= SEQUENCE {
        scvpVersion                INTEGER }

   The scvpVersion item is described in section 3.1.

6 Validation Policies Response

   In response to a VPRequest, the SCVP server provides a VPResponse.
   When a VPResponse is encapsulated in a MIME body part, it MUST be
   carried in an application/scvp-policies-response MIME body part.

   The request consists of a VPRequest encapsulated in a ContentInfo.
   The response is not signed by the server.

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

   The VPResponse type has the following syntax:

      ValPoliciesResponse ::= SEQUENCE {
        scvpVersion                INTEGER,
        valPolicies                SEQUENCE OF OBJECT IDENTIFIER }



Malpani, Housley, & Freeman                                    [Page 31]

INTERNET DRAFT                    SCVP                     December 2002


   The scvpVersion item is described in section 3.1.

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

7 SCVP Server Relay

   In some network environments, especially ones that include firewalls,
   an SCVP server might not be able to obtain all of the information
   that it needs to process a request. However, the server might be
   configured to use the services of one or more other SCVP servers to
   fulfill all requests. In such cases, the SCVP client is unaware that
   the initial SCVP server is using the services of other SCVP servers.
   The initial SCVP server acts as a client to another SCVP server.
   Unlike the original client, the SCVP server is expected to have
   moderate computing and memory resources.  This section describes SCVP
   server-to-SCVP server exchanges. This section does 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.



Malpani, Housley, & Freeman                                    [Page 32]

INTERNET DRAFT                    SCVP                     December 2002


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

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS

     AlgorithmIdentifier, Certificate, Extensions, Name,
     SubjectPublicKeyInfo
       FROM PKIX1Explicit88 -- RFC 3280
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0) 18 }

     AttributeCertificate
       FROM PKIXAttributeCertificate -- RFC 3281
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0) 12 }

     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 }










Malpani, Housley, & Freeman                                    [Page 33]

INTERNET DRAFT                    SCVP                     December 2002


   Query ::= SEQUENCE {
     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                CertChecks,
     wantBack              WantBack,
     serverContextInfo [0] OCTET STRING OPTIONAL,
     valPolicy         [1] ValidationPolicy OPTIONAL,
     validityTime      [2] GeneralizedTime OPTIONAL,
     trustAnchors      [3] TrustAnchors OPTIONAL,
     intermediateCerts [4] CertBundle OPTIONAL,
     revInfos          [5] RevocationInfos OPTIONAL,
     queryExtensions   [6] Extensions OPTIONAL }

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

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

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

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

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

   ValidationPolicy ::= SEQUENCE {
     valPolicyId           OBJECT IDENTIFIER,
     parameters            ANY DEFINED BY valPolicyId OPTIONAL }

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

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

   TrustAnchorInfo ::= CHOICE {
     certRef                 PKCReference,
     rawInfo             [3] RawTrustAnchorInfo }

   RawTrustAnchorInfo ::= SEQUENCE {
     name                    Name,
     algorithm               AlgorithmIdentifier,
     pubKey                  BIT STRING }



Malpani, Housley, & Freeman                                    [Page 34]

INTERNET DRAFT                    SCVP                     December 2002


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

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

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


   -- SCVP Certificate Validation Request

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

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

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

   SCVPStatusCode ::= ENUMERATED {
     okay                    (0),
     skipUnrecognizedItems   (1),
     tooBusy                (10),
     badStructure           (20),
     unsupportedVersion     (21),
     abortUnrecognizedItems (22),
     unrecognizedSigKey     (23),
     badSignature           (24),
     unableToDecode         (25),
     notAuthorized          (26),
     unsupportedChecks      (27),
     unsupportedWantBacks   (28),
     unsupportedSignature   (29),
     invalidSignature       (30),
     relayingLoop           (40) }






Malpani, Housley, & Freeman                                    [Page 35]

INTERNET DRAFT                    SCVP                     December 2002


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

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

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

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

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

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

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

   ReplyChecks ::= SEQUENCE OF ReplyCheck

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




Malpani, Housley, & Freeman                                    [Page 36]

INTERNET DRAFT                    SCVP                     December 2002


   ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

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


   -- SCVP Validation Policies Request

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

   VPRequest ::= SEQUENCE {
     scvpVersion                INTEGER }


   -- SCVP Validation Policies Response

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

   ValPoliciesResponse ::= SEQUENCE {
     scvpVersion                INTEGER,
     valPolicies                SEQUENCE OF OBJECT IDENTIFIER }


   -- SCVP Check Identifiers

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

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

   -- SCVP WantBack Identifiers

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

   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 }



Malpani, Housley, & Freeman                                    [Page 37]

INTERNET DRAFT                    SCVP                     December 2002


   id-swb-pkc-public-key-info   OBJECT IDENTIFIER ::= { id-swb 4 }
   id-swb-aa-cert-path          OBJECT IDENTIFIER ::= { id-swb 5 }
   id-swb-aa-revocation-info    OBJECT IDENTIFIER ::= { id-swb 6 }
   id-swb-ac-revocation-info    OBJECT IDENTIFIER ::= { id-swb 7 }
   id-swb-ac-cert-status        OBJECT IDENTIFIER ::= { id-swb 8 }


   -- SCVP Validation Policy Identifiers

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

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


   -- SCVP Revocation Information Identifiers
   id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) 16 }

   id-ri-crl                    OBJECT IDENTIFIER ::= { id-ri 1 }
   id-ri-ocsp-response          OBJECT IDENTIFIER ::= { id-ri 2 }
   id-ri-delta-crl              OBJECT IDENTIFIER ::= { id-ri 3 }

   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



Malpani, Housley, & Freeman                                    [Page 38]

INTERNET DRAFT                    SCVP                     December 2002


   does not check that the requestNonce in the response matches the
   value in the request, an attacker can replay previous responses from
   the SCVP server.

   If the server does not require some sort of authorization (such as
   signed requests), an attacker can get the server to respond to
   arbitrary requests. Such responses may give the attacker information
   about weaknesses in the server or about the timeliness of the
   server's checking. This information may be valuable for a future
   attack.

   If the server uses the serverContextInformation to indicate some
   server state associated with a requestor, implementers must take
   appropriate measures against denial of service attacks where an
   attacker sends in a lot of requests at one time to force the server
   to keep a lot of state information.

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

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

10 References

   Normative and informative references are provided.

10.1 Normative References

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

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

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






Malpani, Housley, & Freeman                                    [Page 39]

INTERNET DRAFT                    SCVP                     December 2002


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

10.2 Informative References

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

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

11 Acknowledgments

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









Malpani, Housley, & Freeman                                    [Page 40]

INTERNET DRAFT                    SCVP                     December 2002


Appendix A -- MIME Registrations

   Four MIME type registrations are provided in this appendix.

A.1 application/scvp-request

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

   MIME media type name: application

   MIME subtype name: scvp-request

   Required parameters: format

   Optional parameters: None

   Encoding considerations: binary

   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>








Malpani, Housley, & Freeman                                    [Page 41]

INTERNET DRAFT                    SCVP                     December 2002


A.2 application/scvp-response

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

   MIME media type name: application

   MIME subtype name: scvp-response

   Required parameters: format

   Optional parameters: None

   Encoding considerations: binary

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

   Interoperability considerations: None

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

   Applications which use this media type: SCVP servers

   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>













Malpani, Housley, & Freeman                                    [Page 42]

INTERNET DRAFT                    SCVP                     December 2002


A.3 application/scvp-policies-request

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

   MIME media type name: application

   MIME subtype name: scvp-policies-request

   Required parameters: format

   Optional parameters: None


   Encoding considerations: binary

   Security considerations: Carries a request for information.

   Interoperability considerations: None

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

   Applications which use this media type: SCVP clients

   Additional information:

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

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

   Intended usage: COMMON

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













Malpani, Housley, & Freeman                                    [Page 43]

INTERNET DRAFT                    SCVP                     December 2002


A.4 application/scvp-policies-response

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

   MIME media type name: application

   MIME subtype name: scvp-policies-response

   Required parameters: format

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: None

   Interoperability considerations: None

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

   Applications which use this media type: SCVP servers

   Additional information:

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

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

   Intended usage: COMMON

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














Malpani, Housley, & Freeman                                    [Page 44]

INTERNET DRAFT                    SCVP                     December 2002


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.










Malpani, Housley, & Freeman                                    [Page 45]

INTERNET DRAFT                    SCVP                     December 2002


Appendix C -- Author Contact Information

   Ambarish Malpani
   Malpani Consulting Services
   ambarish@malpani.biz

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   rhousley@rsasecurity.com

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
































Malpani, Housley, & Freeman                                    [Page 46]

INTERNET DRAFT                    SCVP                     December 2002


Full Copyright Statement

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

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

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























Malpani, Housley, & Freeman                                    [Page 47]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/