Internet Draft                                             A. Malpanidraft-ietf-pkix-scvp-11.txt               Malpani Consulting ServicesDecember 2002                                              R. HousleyExpires 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 2002Table 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 . . . . . . . . . . . . . . . . . . . . . . . .  32Malpani, Housley, & Freeman                                     [Page 2]INTERNET DRAFT                    SCVP                     December 2002 9 Security Considerations . . . . . . . . . . . . . . . . . . . . .  3810 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  39   10.1 Normative References . . . . . . . . . . . . . . . . . . . .  39   10.2 Informative References . . . . . . . . . . . . . . . . . . .  4011 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40Appendix 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  . . . . . . . . . . . . .  44Appendix B -- SCVP over HTTP . . . . . . . . . . . . . . . . . . . .  45   B.1 SCVP Request  . . . . . . . . . . . . . . . . . . . . . . . .  45   B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . . . .  45Appendix C -- Author Contact Information . . . . . . . . . . . . . .  46Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  47Malpani, Housley, & Freeman                                     [Page 3]INTERNET DRAFT                    SCVP                     December 20021 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 areMalpani, 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