[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-10.txt                    Independent Consultant
October 2002                                               R. Housley
Expires in six months                                RSA Laboratories
                                                           T. Freeman
                                                       Microsoft Corp

             Simple Certificate Validation Protocol (SCVP)

Status of this memo

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

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

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

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

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

Copyright Notice

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

Abstract

   SCVP allows a client to offload certificate handling to a server. The
   server can prove the client with a variety of valuable information
   about the certificate, such as whether the certificate is valid, a
   certification path to a trust anchor, and so on. SCVP has many
   purposes, including simplifying client implementations and allowing
   companies to centralize trust and policy management.

1 Introduction

   Certificate validation is complex. If certificate handling is to be
   widely deployed in a variety of applications and environments, the
   amount of processing an application needs to perform before it can



Malpani, Housley, & Freeman                                     [Page 1]


INTERNET DRAFT                    SCVP                      October 2002


   accept a certificate needs to be reduced. There are a variety of
   applications that can make use of public key certificates, but these
   applications are burdened with the overhead of constructing and
   validating the certification paths. SCVP reduces this overhead for
   two classes of certificate-using applications.

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

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

1.1 SCVP overview and requirements

   The SCVP meets the requirements documented in [RQMTS].

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

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

   Trusted SCVP servers can perform certification path construction and
   validation for the client. For a client uses these services, the
   client inherently trusts the SCVP server as much as it would its own
   path validation software (if it contained such software). There are
   two main reasons that a client may want to trust such an SCVP server:

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



Malpani, Housley, & Freeman                                     [Page 2]


INTERNET DRAFT                    SCVP                      October 2002


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

1.2 Terminology

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

1.3 Open Issues

   The following is a list of issues that were raised on earlier
   versions of this document that have not been fully dealt with here.
   Comments on these issues are particularly welcome.

      - Extensions can be marked as critical. The usefulness and
        problems of criticality have been long debated and there has not
        been a great deal of consensus. In SCVP, marking a request
        extension as critical says to the server "don't give me an
        answer unless you understand this extension", and marking a
        response extension as critical says "don't use this response
        unless you understand this extension". Without the critical bit
        in the extensions, either the semantics of extensions would have
        to be changed to essentially say "all extensions are critical"
        (which is overkill for some extensions that might really be
        optional), or the semantics would have to be changed to say "you
        can never rely on the other party understanding an extension",
        which would limit the usefulness of some extensions.

      - Should the response contain a unique identifier assigned by
        the SCVP server?  It would allow easily reference a SCVP
        response, permitting external reference by SCVP server  and
        response identifier.

      - The structure allows for the validation of other objects, such
        as attribute certificates, to be easily added as Query CHOICE
        items.  Should we change the name of the protocol to reflect
        this flexibility?  Or should we drop the flexibility?

      - Can CertBundle contain objects of a different type than the
        object being queried?  For example, if the client wants the
        server to validate a public key certificate, can the CertBundle
        contain an attribute certificate?

      - Can TrustAnchors contain objects of a different type than the
        object being queried?  For example, if, in the future, the



Malpani, Housley, & Freeman                                     [Page 3]


INTERNET DRAFT                    SCVP                      October 2002


        client wants the server to validate a attribute certificate, can
        the CertBundle contain a public key certificate?

      - Should TrustAnchors contain constraints?  It already permits
        a specific set of certificate policies, but should other
        constraints be allowed.  For example, should the client be
        able to impose name constraints on a particular trust anchor?

      - Should we require the certReplies SEQUENCE items to be listed in
        a particular order?

      - ReplyTypesOfCheck and ReplyWantBack use the Extensions
        structure.  What does the critical bit mean?  Should a different
        structure be used?

      - Update discussion of validation policy to allow client to
        identify the application context to the server.  The SCVP server
        MUST validate the certificate for that context, such as SSL/TLS,
        S/MIME, or IPsec.  Are there others?

      - TO DO: Fully specify transport, building on MIME type
        specifications.

      - TO DO: Explain relaying and referral processing.

      - TO DO: Show how to delegate SCVP signing authority.

      - TO DO: Allow the response to be unsigned if it is simply
        reporting an error.  Generating malformed requests should not
        force the server to perform a private key operation.

      - TO DO: Move error codes that apply to the whole request up a
        level.

2 Protocol

   The SCVP protocol uses a simple request-response model. That is, the
   SCVP client creates a request and sends it to the SCVP server, and
   then the SCVP server creates a single response and sends it to the
   client. Typical use of SCVP is expected to be over HTTP, and possibly
   email. In Appendix B, this document registers MIME types for SCVP
   requests and responses.

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

   Section 5 defines the validation policies request and the
   corresponding response.



Malpani, Housley, & Freeman                                     [Page 4]


INTERNET DRAFT                    SCVP                      October 2002


3 Validation Request

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

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

   The unsigned request consists of a PSRequest encapsulated in a
   ContentInfo.  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-psRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
        content            PSRequest }

   The signed request consists of a PSRequest encapsulated in a
   SignedData which is in turn encapsulated in a ContentInfo.  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)



Malpani, Housley, & Freeman                                     [Page 5]


INTERNET DRAFT                    SCVP                      October 2002


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

   The syntaxes for SignedData and ContentInfo are defined in [CMS]. The
   syntax for PSRequest is defined below. The PSRequest item contains
   the client request. The "PS" in PSRequest means "possibly signed".
   The PSRequest item contains scvpVersion, query, typesOfCheck, and
   wantBack items. It MAY also contain a requestor, requestNonce, and
   reqExtensions items.

   The scvpVersion item MUST contain the integer one (1).

   The query item MUST contain a Query. This specification includes only
   the CertsQuery; however, the use of a CHOICE permits future versions
   of this protocol to support validation of other objects.

   The typesOfCheck item MUST contain a sequence of object identifiers.
   Each object identifier tells the server what types of checking the
   client expects the server to perform on the on the query item(s).

   The wantBack item MUST contain a sequence of object identifiers. Each
   object identifier tells the server what the client wants to know
   about the query item(s).

   The requestor item MAY contain an octet string. If present, the octet
   string contains a locally generated identifier of the client. No
   provisions are made to ensure uniqueness of the requestor octet
   string.

   The requestNonce item MAY contain an octet string. If present, the
   octet string MUST contain an identifier generated by the client for
   the request.

   The reqExtensions item MAY contain Extensions.  If present, each
   Extension in the sequence extends the request. For example, an
   Extension MAY be used to request a different type of item.

   The PSRequest MUST have the following syntax:

      PSRequest ::= SEQUENCE {
        scvpVersion           INTEGER,
        query                 Query,
        checks                CertChecks,
        wantBack              WantBack,
        requestor         [0] OCTET STRING OPTIONAL,
        requestNonce      [1] OCTET STRING OPTIONAL,



Malpani, Housley, & Freeman                                     [Page 6]


INTERNET DRAFT                    SCVP                      October 2002


        reqExtensions     [2] Extensions OPTIONAL }

3.1 scvpVersion

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

3.2 Query

   The Query specifies one or more items, and these items are the object
   of the request. One type of object is defined in this specification:
   CertsQuery. However, other types of queries can be specified in the
   future. The CertsQuery is a request for information regarding one or
   more certificates. A CertsQuery MUST contain a sequence of one or
   more certificate reference. A CertsQuery MAY also contain
   serverContextInfo, validityTime, intermediateCerts, trustedCerts,
   revInfos, certPolicies, configID, and queryExtensions items. Query
   MUST have the following syntax:

      Query ::= CHOICE {
        certsQuery        [0] CertsQuery }

      CertsQuery ::= SEQUENCE {
        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference,
        serverContextInfo [0] OCTET STRING OPTIONAL,
        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
   intermediateCerts, trustedCerts, revInfos, certPolicies, and
   valPolicy items provide context for the client request.

3.2.1 queriedCerts

   The queriedCerts item, using the CertReference type, MUST contain at
   least one certificate reference. The CertReference contains either
   the certificate or a reference to the certificate. Certificate
   references use the ESSCertID type defined in [ESS]. CertReference has



Malpani, Housley, & Freeman                                     [Page 7]


INTERNET DRAFT                    SCVP                      October 2002


   the following syntax:

      CertReference ::= CHOICE {
        pkixCert          [1] Certificate,
        certId            [2] ESSCertID }

   The ASN.1 definition of Certificate is imported from [PKIX]. The
   definition of ESSCertID is imported from [ESS].

3.2.2 serverContextInfo

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

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

3.2.3 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 certPolicies and trustedCerts. The value of this item is
   determined by private agreement between the client and the server,
   but it MUST be represented as an OBJECT IDENTIFIER. The server might
   want to assign identifiers that indicate that some settings are used
   in addition to others given in the request. In this way, the
   configuration identifier might be a shorthand for some SCVP options,
   but not others.

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

      ValidationPolicy ::= SEQUENCE {



Malpani, Housley, & Freeman                                     [Page 8]


INTERNET DRAFT                    SCVP                      October 2002


        valPolicyId           OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valPolicyId OPTIONAL }

   If no validation policy is specified in the request, then the default
   validation policy is used. The default validation policy may also be
   explicitly specified. The OBJECT IDENTIFIER to identify the default
   validation policy is:

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

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

   The meaning of this policy is:
      - Trust anchors will come from the trustedCerts field. If no
        certificates are specified in the trustedCerts field, then
        the server may use trust anchors of its own choosing.

      - The acceptable policy set will come from the certPolicies field.
        If no policy is specified there, then any-policy is used.

3.2.4 validityTime

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

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

   The information in the corresponding CertReply item in the response
   MUST be formatted as if the server created the response at the time
   indicated in the validityTime. However, if the server does not have
   appropriate historical information, the server MAY either return an
   error or return information for a later time. A client MUST be
   prepared to handle responses that contain respValTime items that do
   not match the requested validityTime.

3.2.5 trustAnchors

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



Malpani, Housley, & Freeman                                     [Page 9]


INTERNET DRAFT                    SCVP                      October 2002


   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 is not important.

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

   The pathLenConstraint optional item specifies the maximum non-
   negative number of non-self-issued intermediate certificates that may
   follow this trust anchor in a valid certification path.  A
   certificate is self-issued if the DNs that appear in the subject and
   issuer fields are identical and are not empty.  The last certificate
   in the certification path is not an intermediate certificate, and is
   not    included in this limit. A pathLenConstraint of zero indicates
   that only one more certificate may follow in a valid certification
   path.  Where pathLenConstraint does not appear, no limit is imposed.

   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
        pathLenConstraint [2] INTEGER (0..MAX) OPTIONAL }
                              -- if absent, any length is allowed

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

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

3.2.6 intermediateCerts

   The intermediateCerts item helps the server create valid



Malpani, Housley, & Freeman                                    [Page 10]


INTERNET DRAFT                    SCVP                      October 2002


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

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

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

3.2.7 revInfos

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

   The types of revocation information that can be provided are: a CRL
   or an OCSP response.

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

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

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

   The object identifiers for riType for CRLs and OCSP are id-ri-crl and
   id-ri-ocsp-response, respectively.

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

      id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 }




Malpani, Housley, & Freeman                                    [Page 11]


INTERNET DRAFT                    SCVP                      October 2002


      id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }

3.2.8 queryExtensions

   The queryExtensions item specifies a list of extensions to the SCVP
   protocol. For example, a client might request additional information
   about the certificate(s) in the CertsQuery. The syntax for Extensions
   is imported from [PKIX]. The queryExtensions item, when present,
   contains a sequence of Extension items, each of which contains an
   extnID item, a critical item, and an extnValue item.

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

   The critical item is a BOOLEAN that tells whether the extension is
   critical. The values for the item are:
      - FALSE (Not critical)
      - TRUE  (Critical)

   In a request, if the critical item is TRUE, the server MUST NOT
   process the request unless it understands the extension. In a reply,
   if the critical item is TRUE, the client MUST NOT process the
   response unless it understands the extension.

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

3.3 checks

   The checks item describes the checking that the client wants the
   server to perform on the certificate(s) in the query item. If the
   checks item is present in a request, it can contain one or more types
   of check. For each type of check specified in the request, the server
   MUST perform all the checks requested, or return an error.

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

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

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

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



Malpani, Housley, & Freeman                                    [Page 12]


INTERNET DRAFT                    SCVP                      October 2002


   item.

   OIDs are defined for these types of checks:
      - Build a certification path to a trusted root.
      - Build a validated certification path to a trusted root.
      - Do revocation status checks on the certification path.

   For these purposes, the following OIDs are defined:

      id-stc OBJECT IDENTIFIER ::= { id-pkix 17 }

      id-stc-build-path       OBJECT IDENTIFIER ::= { id-stc 1 }

      id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 }

      id-stc-build-valid-status-checked-path
                              OBJECT IDENTIFIER ::= { id-stc 3 }

3.4 wantBack

   The wantBack item describes the kind of information the client wants
   from the server for the certificate(s) in the Query item. The
   wantBack item MUST contain one or more types of information. For each
   type of information specified in the request, the server MUST return
   information regarding its finding (in a successful response).

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

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

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

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




Malpani, Housley, & Freeman                                    [Page 13]


INTERNET DRAFT                    SCVP                      October 2002


   The types of information that can be requested are:
      - Certification path built for the certificate
      - Proof of revocation status
      - Status indication

   For these purposes, the following OIDs are defined:

      id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }  -- SCVP want back

      id-swb-cert-path       OBJECT IDENTIFIER ::= { id-swb 1 }
      id-swb-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
      id-swb-cert-status     OBJECT IDENTIFIER ::= { id-swb 3 }

3.5 requestor

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

   The requestor item uses the OCTET STRING type.

3.6 requestNonce

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

   The requestNonce item uses the OCTET STRING type.

3.7 reqExtensions

   The reqExtensions optional item specifies a list of extensions to the
   request. The reqExtensions item contains a sequence of Extension
   items, each of which contains an extnID item, a critical item, and an
   extnValue item.

   The syntax and semantics of these items are described in section
   3.2.9.

4 Validation Response

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



Malpani, Housley, & Freeman                                    [Page 14]


INTERNET DRAFT                    SCVP                      October 2002


   MIME body part.

   There are two forms of an SCVP response: unsigned and signed. An
   unsigned MUST only be generated for an error status. An 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-psResponse,
                                    -- (1.2.840.113549.1.9.16.1.11)
        content            PSResponse }

   The signed response consists of a PSResponse encapsulated in a
   SignedData which is in turn encapsulated in a ContentInfo.  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, -- (MUST include server cert)
        crls               CertificateRevocationLists, -- (Optional)
        signerInfos        SET OF SignerInfos } -- Only 1 in SCVP

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

      EncapsulatedContentInfo {
        eContentType       id-ct-scvp-psResponse,
                                    -- (1.2.840.113549.1.9.16.1.11)
        eContent           OCTET STRING } -- Contains PSResponse

   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.



Malpani, Housley, & Freeman                                    [Page 15]


INTERNET DRAFT                    SCVP                      October 2002


   The signedAttrs within SignerInfo MUST include SigningCertificate
   attribute as defined in [ESS]. The first certificate identified in
   the sequence of certificate identifiers MUST be the certificate of
   the SCVP server. The inclusion of other certificate identifiers is
   OPTIONAL. The inclusion of policies is also OPTIONAL.

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

   The PSResponse MUST have the following syntax:

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

4.1 scvpVersion

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

4.2 producedAt

   The producedAt item tells the date and time at which the server
   generated the response. The producedAt item represents the date and
   time in UTC.

   The producedAt item uses the GeneralizedTime type.

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




Malpani, Housley, & Freeman                                    [Page 16]


INTERNET DRAFT                    SCVP                      October 2002


   This rule for GeneralizedTime applies to all occurrences of
   GeneralizedTime in this specification and is the same as the rule
   used in certificate profiles [PKIX].

4.3 responseStatus

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

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

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

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

      SCVPStatusCode ::= ENUMERATED {
        okay                    (0),
        skipUnrecognizedItems   (1),
        tooBusy                (10),
        badStructure           (20),
        unsupportedVersion     (21),
        abortUnrecognizedItems (22),
        unrecognizedSigKey     (23),
        badSignature           (24),
        unableToDecode         (25),
        notAuthorized          (26) }

   The meaning of the various SCVPStatusCode values are:

       0  The request was fully processed
       1  The request included unrecognized items; continuing

      10  Too busy; try again later

      20  The structure of the request was wrong
      21  The version of request is not supported by this server
      22  The request included unrecognized items; aborting
      23  The key given in the RequestSignature is not recognized
      24  The signature did not match the body of the request



Malpani, Housley, & Freeman                                    [Page 17]


INTERNET DRAFT                    SCVP                      October 2002


      25  The encoding was not understood
      26  The request was not authorized
      27  The request included unsupported items; continuing
      28  The request included unsupported items; aborting

4.4 requestReference

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

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

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

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

      RequestReference ::= CHOICE {
        requestHash           HashValue, -- hash of PSRequest
        fullRequest           PSRequest }

4.4.1 requestHash

   The requestHash item is the hash of the PSRequest. 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. (Although, 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             AgorithmIdentifier DEFAULT { sha-1 },
        value                 OCTET STRING }

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)



Malpani, Housley, & Freeman                                    [Page 18]


INTERNET DRAFT                    SCVP                      October 2002


          oiw(14) secsig(3) algorithm(2) 26 }

4.4.2 fullRequest

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

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

4.5 requestor

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

   The requestor item uses the OCTET STRING type.

4.6 responder

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

   The responder item uses the OCTET STRING type.

4.7 replyObjects

   The replyObjects item returns requested objects to the client. In
   this specification, the replyObjects item is always a certReplies,
   which is a sequence of CertReply, each of which tells the client
   about a single certificate from the request. The CertReply item MUST
   contain cert, replyStatus, and respValTime items, and it MAY contain
   a nextUpdate item. The CertReply MAY also contain the
   replyTypesOfCheck, replyWantBack, and singleReplyExtensions optional
   items.

   The typesOfCheck, wantBack, and queryExtension items in the request
   control the presence or absence of the replyTypesOfCheck,
   replyWantBack, and singleReplyExtensions optional items in the
   response. A server MUST include one of the above items for each
   related item requested in the typesOfCheck, and wantBack items.

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



Malpani, Housley, & Freeman                                    [Page 19]


INTERNET DRAFT                    SCVP                      October 2002


      ReplyObjects ::= CHOICE {
        certReplies            [0] SEQUENCE SIZE (1..MAX) OF CertReply }

      CertReply ::= SEQUENCE {
        cert                       Certificate,
        replyStatus                ReplyStatus,
        respValTime                GeneralizedTime,
        nextUpdate             [0] GeneralizedTime OPTIONAL,
        replyTypesOfCheck      [1] Extensions OPTIONAL,
        replyWantBack          [2] Extensions OPTIONAL,
        singleReplyExtensions  [3] Extensions OPTIONAL }

4.7.1 cert

   The cert item contains the certificate about which the client is
   requesting information.

   The cert item uses the Certificate type, which is defined in [PKIX].

4.7.2 replyStatus

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

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

      ReplyStatus ::= ENUMERATED {
        success                  (0),
        certTypeUnrecognized     (1),
        typeOfCheckUnrecognized  (2),
        wantBackUnrecognized     (3),
        certMalformed            (4),
        policyIDUnrecognized     (5),
        configInfoUnrecognized   (6) }

   The meaning of the various ReplyStatus values are:

      0  Success: a definitive answer follows
      1  Failure: the certificate type is not recognized
      2  Failure: an item wanted in TypesOfCheck is not recognized
      3  Failure: an item wanted in WantBack is not recognized
      4  Failure: the certificate was malformed
      5  Failure: the mandatory PolicyID is not recognized
      6  Failure: the ConfigurationIdentifier is not recognized



Malpani, Housley, & Freeman                                    [Page 20]


INTERNET DRAFT                    SCVP                      October 2002


      7  Failure: unauthorized request
      8  Failure: unsupported validation policy

   Status code 4 is used to tell the client that the request was
   properly formed but the certificate in question was not. This is
   useful to clients that cannot parse a certificate.

4.7.3 respValTime

   The respValTime item tells the time at which the information in the
   CertReply was correct. The respValTime item represents the date and
   time in UTC.

   The respValTime item uses the GeneralizedTime type. The encoding
   rules for GeneralizedTime in section 4.2 MUST be used.

4.7.4 nextUpdate

   The nextUpdate item tells the time at which the server expects
   additional information regarding the validity of the certificate to
   become available. Such information could change the status of the
   certificate; however, it might not change the status of the
   certificate. The nextUpdate is especially interesting if the
   certificate revocation status information is not available or the
   certificate is suspended. This should be said. The nextUpdate item
   represents the date and time in UTC.

   The nextUpdate item uses the GeneralizedTime type. The encoding rules
   for GeneralizedTime in section 4.2 MUST be used.

4.7.5 replyTypesOfCheck

   The replyTypesOfCheck contains the responses to the typesOfCheck item
   in the request. The replyTypesOfCheck item uses the Extensions type.
   The syntax of the Extensions type is discussed in section 3.2.9. The
   object identifiers (OIDs) in the typesOfCheck item in the request are
   used to identify the corresponding reply value. The OIDs in the
   replyTypesOfCheck item MUST match the OIDS in the typesOfCheck item
   in the request. The criticality bit MUST NOT be set.

   The value for path building to a trusted root, {type-arc 0}, can be
   one of the following:

      Value         Meaning
      -----         -------
        0           Built a path
        1           Could not build a path




Malpani, Housley, & Freeman                                    [Page 21]


INTERNET DRAFT                    SCVP                      October 2002


   The value for path validation to a trusted root, {type-arc 1}, can be
   one of the following:

      Value         Meaning
      -----         -------
        0           Valid
        1           Not valid

   The value for the revocation status, {type-arc 2}, can be one of the
   following:

      Value         Meaning
      -----         -------
        0           Good
        1           Revoked
        2           Unknown

4.7.6 replyWantBack

   The replyWantBack contains the responses to the wantBack item in the
   request. The replyWantBack item uses the Extensions type. The syntax
   of the Extensions type is discussed in section 3.2.9. The object
   identifiers (OIDs) in the wantBack item in the request are used to
   identify the corresponding reply value. The OIDs in the replyWantBack
   item MUST match the OIDS in the wantBack item in the request. The
   criticality bit MUST NOT be set.

   The extnValue for the certification chain used to verify the
   certificate in the request, {want-arc 0}, uses the CertBundle type.
   The syntax and semantics of the CertBundle type are described in
   section 3.2.6.

   The extnValue for the proof of revocation status, {want-arc 1}, uses
   the RevocationInfo type. The syntax and semantics of the
   RevocationInfo type are described in section 3.2.7.

4.7.7 singleReplyExtensions

   The singleReplyExtensions contains the responses to the
   queryExtension item in the request. The singleReplyExtensions item
   uses the Extensions type. The syntax of the Extensions type is
   discussed in section 3.2.9. The object identifiers (OIDs) in the
   queryExtension item in the request are used to identify the
   corresponding reply value. The OIDs in the queryExtension item MUST
   match the OIDS in the singleReplyExtensions item in the request. The
   criticality bit MUST NOT be set.

4.8 requestNonce



Malpani, Housley, & Freeman                                    [Page 22]


INTERNET DRAFT                    SCVP                      October 2002


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

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

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

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

4.10 respExtensions

   The respExtensions optional item specifies a list of extensions to
   the response. The respExtensions item contains a sequence of
   Extension items, each of which contains an extnID item, a critical
   item, and an extnValue item.

   The syntax and semantics of these items are described in section
   3.2.9.

5 Validation Policies

   A SCVP server also needs to be able to inform a client about the
   validation policies it supports. For this purpose, SCVP defines a
   simple request-response pair.

5.1 Validation Policies Request

   A SCVP client request to the server to ask about the validation



Malpani, Housley, & Freeman                                    [Page 23]


INTERNET DRAFT                    SCVP                      October 2002


   policies it supports be a single ValPoliciesRequest item. When a
   ValPoliciesRequest 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 ValPoliciesRequest encapsulated in a
   ContentInfo.

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

   The ValPoliciesRequest type has the following syntax:

      ValPoliciesRequest ::= SEQUENCE {
        scvpVersion                INTEGER }

   The scvpVersion item is described in section 3.1.

5.2 Validation Policies Response

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

   The request consists of a ValPoliciesRequest encapsulated in a
   ContentInfo.

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

   The ValPoliciesResponse type has the following syntax:

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

   The scvpVersion item is described in section 3.1.

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

6 ASN.1 Syntax for SCVP




Malpani, Housley, & Freeman                                    [Page 24]


INTERNET DRAFT                    SCVP                      October 2002


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


   SCVP DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   IMPORTS

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

     ContentInfo, SignedData
       FROM CryptographicMessageSyntax -- RFC 3369
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) cms-2001(14) }

     ESSCertID
       FROM ExtendedSecurityServices -- RFC 2634
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) ess(2) };

   <TBD>

   END

7 Security Considerations

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

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

   When the SCVP response is used to determine the validity of a
   certificate, the client MUST validate the signature on the response



Malpani, Housley, & Freeman                                    [Page 25]


INTERNET DRAFT                    SCVP                      October 2002


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

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

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

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

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

8 References

   Normative and informative references are provided.

8.1 Normative References

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

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

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

   [PKIX]       Housley, R., Polk, T, Ford, W. and Solo, D., "Internet



Malpani, Housley, & Freeman                                    [Page 26]


INTERNET DRAFT                    SCVP                      October 2002


                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

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

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

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

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

   [RQMTS]      Pinkas, D., and R. Housley, "Delegated Path Validation
                and Delegated Path Discovery Protocol Requirements",
                <draft-ietf-pkix-dpv-dpd-req-05.txt>.

9 Acknowledgments

   The lively debate in the PKIX Working Group also had a significant
   impact this protocol. Denis Pinkas suggested some additional
   requirements for the protocol, and Mike Myers identified areas that
   needed clarification. Frank Balluffi and Ameya Talwalkar did an
   implementation based on an early draft of this protocol, and they
   identified a few deficiencies. John Thielens and Peter Sylvester
   provided a lot of good input that improved this document.

Appendix A -- MIME Registrations

   Four MIME type registrations are provided in this appendix.

A.1 application/scvp-request

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

   MIME media type name: application

   MIME subtype name: scvp-request

   Required parameters: format

   Optional parameters: None




Malpani, Housley, & Freeman                                    [Page 27]


INTERNET DRAFT                    SCVP                      October 2002


   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@valicert.com>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

A.2 application/scvp-response

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

   MIME media type name: application

   MIME subtype name: scvp-response

   Required parameters: format

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a cryptographically signed response

   Interoperability considerations: None

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




Malpani, Housley, & Freeman                                    [Page 28]


INTERNET DRAFT                    SCVP                      October 2002


   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@valicert.com>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

A.3 application/scvp-policies-request

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

   MIME media type name: application

   MIME subtype name: scvp-policies-request

   Required parameters: format

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a request for information.

   Interoperability considerations: None

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

   Applications which use this media type: SCVP clients

   Additional information:

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

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



Malpani, Housley, & Freeman                                    [Page 29]


INTERNET DRAFT                    SCVP                      October 2002


   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

A.4 application/scvp-policies-response

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

   MIME media type name: application

   MIME subtype name: scvp-policies-response

   Required parameters: format

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: None

   Interoperability considerations: None

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

   Applications which use this media type: SCVP servers

   Additional information:

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

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

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

Appendix B -- SCVP over HTTP

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




Malpani, Housley, & Freeman                                    [Page 30]


INTERNET DRAFT                    SCVP                      October 2002


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

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

B.2 SCVP Response

   An HTTP-based SCVP response is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   FullResponse. The Content-Type header MUST have the value
   "application/scvp-response".  The Content-Length header MUST be
   present and specify the length of the response. Other HTTP headers
   MAY be present and MAY be ignored if not understood by the requestor.

Appendix C -- Author Contact Information

   Ambarish Malpani
   Independent Consultant
   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 31]


INTERNET DRAFT                    SCVP                      October 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 32]


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