draft-ietf-pkix-scvp-11.txt

PKIX的RFC英文文档

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