Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5055

Server-Based Certificate Validation Protocol (SCVP)

Pages: 88
Proposed Standard
Part 1 of 4 – Pages 1 to 9
None   None   Next

Top   ToC   RFC5055 - Page 1
Network Working Group                                        T. Freeman
Request for Comments: 5055                               Microsoft Corp
Category: Standards Track                                    R. Housley
                                                         Vigil Security
                                                             A. Malpani
                                            Malpani Consulting Services
                                                              D. Cooper
                                                                W. Polk
                                                                   NIST
                                                          December 2007


          Server-Based Certificate Validation Protocol (SCVP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies.

Table of Contents

1. Introduction ....................................................4 1.1. Terminology ................................................4 1.2. SCVP Overview ..............................................5 1.3. SCVP Requirements ..........................................5 1.4. Validation Policies ........................................6 1.5. Validation Algorithm .......................................7 1.6. Validation Requirements ....................................8 2. Protocol Overview ...............................................9 3. Validation Request ..............................................9 3.1. cvRequestVersion ..........................................12 3.2. query .....................................................12 3.2.1. queriedCerts .......................................13 3.2.2. checks .............................................15
Top   ToC   RFC5055 - Page 2
           3.2.3. wantBack ...........................................16
           3.2.4. validationPolicy ...................................19
                  3.2.4.1. validationPolRef ..........................20
                           3.2.4.1.1. Default Validation Policy ......21
                  3.2.4.2. validationAlg .............................22
                           3.2.4.2.1. Basic Validation Algorithm .....22
                           3.2.4.2.2. Basic Validation
                                      Algorithm Errors ...............23
                           3.2.4.2.3. Name Validation Algorithm ......24
                           3.2.4.2.4. Name Validation
                                      Algorithm Errors ...............25
                  3.2.4.3. userPolicySet .............................26
                  3.2.4.4. inhibitPolicyMapping ......................26
                  3.2.4.5. requireExplicitPolicy .....................27
                  3.2.4.6. inhibitAnyPolicy ..........................27
                  3.2.4.7. trustAnchors ..............................27
                  3.2.4.8. keyUsages .................................28
                  3.2.4.9. extendedKeyUsages .........................28
                  3.2.4.10. specifiedKeyUsages .......................29
           3.2.5. responseFlags ......................................30
                  3.2.5.1. fullRequestInResponse .....................30
                  3.2.5.2. responseValidationPolByRef ................30
                  3.2.5.3. protectResponse ...........................31
                  3.2.5.4. cachedResponse ............................31
           3.2.6. serverContextInfo ..................................32
           3.2.7. validationTime .....................................32
           3.2.8. intermediateCerts ..................................33
           3.2.9. revInfos ...........................................34
           3.2.10. producedAt ........................................35
           3.2.11. queryExtensions ...................................35
                  3.2.11.1. extnID ...................................35
                  3.2.11.2. critical .................................35
                  3.2.11.3. extnValue ................................36
      3.3. requestorRef ..............................................36
      3.4. requestNonce ..............................................36
      3.5. requestorName .............................................37
      3.6. responderName .............................................37
      3.7. requestExtensions .........................................38
           3.7.1. extnID .............................................38
           3.7.2. critical ...........................................38
           3.7.3. extnValue ..........................................38
      3.8. signatureAlg ..............................................38
      3.9. hashAlg ...................................................39
      3.10. requestorText ............................................39
      3.11. SCVP Request Authentication ..............................40
   4. Validation Response.............................................40
     4.1. cvResponseVersion...........................................43
     4.2. serverConfigurationID.......................................43
Top   ToC   RFC5055 - Page 3
     4.3. producedAt..................................................44
     4.4. responseStatus..............................................44
     4.5. respValidationPolicy........................................46
     4.6. requestRef..................................................47
           4.6.1. requestHash ........................................47
           4.6.2. fullRequest ........................................48
     4.7. requestorRef................................................48
     4.8. requestorName...............................................48
     4.9. replyObjects................................................49
           4.9.1. cert................................................50
           4.9.2. replyStatus.........................................50
           4.9.3. replyValTime .......................................51
           4.9.4. replyChecks ........................................51
           4.9.5. replyWantBacks .....................................53
           4.9.6. validationErrors ...................................56
           4.9.7. nextUpdate .........................................56
           4.9.8. certReplyExtensions ................................56
     4.10. respNonce..................................................57
     4.11. serverContextInfo..........................................57
     4.12. cvResponseExtensions ......................................58
     4.13. requestorText .............................................58
     4.14. SCVP Response Validation ..................................59
           4.14.1. Simple Key Validation .............................59
           4.14.2. SCVP Server Certificate Validation ................59
   5. Server Policy Request...........................................60
      5.1. vpRequestVersion...........................................60
      5.2. requestNonce...............................................60
   6. Validation Policy Response......................................61
      6.1. vpResponseVersion..........................................62
      6.2. maxCVRequestVersion........................................62
      6.3. maxVPRequestVersion........................................62
      6.4. serverConfigurationID......................................62
      6.5. thisUpdate.................................................63
      6.6. nextUpdate and requestNonce................................63
      6.7. supportedChecks............................................63
      6.8. supportedWantBacks.........................................64
      6.9. validationPolicies.........................................64
      6.10. validationAlgs............................................64
      6.11. authPolicies..............................................64
      6.12. responseTypes.............................................64
      6.13. revocationInfoTypes.......................................64
      6.14. defaultPolicyValues.......................................65
      6.15. signatureGeneration ......................................65
      6.16. signatureVerification ....................................65
      6.17. hashAlgorithms ...........................................66
      6.18. serverPublicKeys .........................................66
      6.19. clockSkew ................................................66
   7. SCVP Server Relay...............................................67
Top   ToC   RFC5055 - Page 4
   8. SCVP ASN.1 Module...............................................68
   9. Security Considerations.........................................76
   10. IANA Considerations............................................78
   11. References.....................................................78
       11.1. Normative References.....................................78
       11.2. Informative References...................................79
   12. Acknowledgments................................................80
   Appendix A. MIME Media Type Registrations..........................81
        A.1. application/scvp-cv-request..............................81
        A.2. application/scvp-cv-response.............................82
        A.3. application/scvp-vp-request..............................83
        A.4. application/scvp-vp-response.............................84
   Appendix B. SCVP over HTTP.........................................85
        B.1. SCVP Request.............................................85
        B.2. SCVP Response............................................85
        B.3. SCVP Policy Request......................................86
        B.4. SCVP Policy Response.....................................86

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 applications wants just two things: confirmation that the public key belongs to the identity named in the certificate and confirmation that the public key can be used for the intended purpose. Such clients can completely delegate certification path construction and validation to the SCVP server. This is often referred to as delegated path validation (DPV). The second class of applications can perform certification path validation, but they lack a reliable or efficient method of constructing a valid certification path. Such clients delegate certification path construction to the SCVP server, but not validation of the returned certification path. This is often referred to as delegated path discovery (DPD).

1.1. 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].
Top   ToC   RFC5055 - Page 5

1.2. SCVP Overview

The primary goals of SCVP are to make it easier to deploy Public Key Infrastructure (PKI)-enabled applications by delegating path discovery and/or validation processing to a server, and to allow central administration of validation 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 the revocation information, such as Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses, that the clients need to validate the certification paths constructed by the SCVP server. These services can be valuable to clients that do not implement the protocols needed to find and download intermediate certificates, CRLs, and OCSP responses. Trusted SCVP servers can perform certification path construction and validation for the client. For a client that uses these services, the client inherently trusts the SCVP server as much as it would its own certification path validation software (if it contained such software). There are two main reasons that a client may want to trust such an SCVP server: 1. The client does not want to incur the overhead of including certification path validation software and running it for each certificate it receives. 2. The client is in an organization or community that wants to centralize management of validation policies. These policies might dictate that particular trust anchors are to be used and the types of policy checking that are to be performed during certification path validation.

1.3. SCVP Requirements

SCVP meets the mandatory requirements documented in [RQMTS] for DPV and DPD.
Top   ToC   RFC5055 - Page 6
   Note that RFC 3379 states the following requirement:

      The DPD response MUST indicate one of the following status
      alternatives:

      1) one or more certification paths was found according to the path
         discovery policy, with all of the requested revocation
         information present.

      2) one or more certification paths was found according to the path
         discovery policy, with a subset of the requested revocation
         information present.

      3) one or more certification paths was found according to the path
         discovery policy, with none of the requested revocation
         information present.

      4) no certification path was found according to the path discovery
         policy.

      5) path construction could not be performed due to an error.

   DPD responses constructed by SCVP servers do not differentiate
   between states 2) and 3).  This property was discussed on the PKIX
   working group list and determined to be conformant with the intent of
   [RQMTS].

1.4. Validation Policies

A validation policy (as defined in RFC 3379 [RQMTS]) specifies the rules and parameters to be used by the SCVP server when validating a certificate. In SCVP, the validation policy to be used by the server either can be fully referenced in the request by the client (and thus no additional parameters are necessary) or can be referenced in the request by the client with additional parameters. Policy definitions can be quite long and complex, and some policies may allow for the setting of a few parameters. The request can therefore be very simple if an object identifier (OID) is used to specify both the algorithm to be used and all the associated parameters of the validation policy. The request can be more complex if the validation policy fixes many of the parameters but allows the client to specify some of them. When the validation policy defines every parameter necessary, an SCVP request needs only to contain the certificate to be validated, the referenced validation policy, and any run-time parameters for the request.
Top   ToC   RFC5055 - Page 7
   A server publishes the references of the validation policies it
   supports.  When these policies have parameters that may be
   overridden, the server communicates the default values for these
   parameters as well.  The client can simplify the request by omitting
   a parameter from a request if the default value published by the
   server for a given validation policy reference is acceptable.
   However, if there is a desire to demonstrate to someone else that a
   specific validation policy with all its parameters has been used, the
   client will need to ask the server for the inclusion of the full
   validation policy with all the parameters in the response.

   The inputs to the basic certification path processing algorithm used
   by SCVP are defined by [PKIX-1] in Section 6.1.1 and comprise:

      Certificate to be validated (by value or by reference);

      Validation time;

      The initial policy set;

      Initial inhibit policy mapping setting;

      Initial inhibit anyPolicy setting; and

      Initial require explicit policy setting.

   The basic certification path processing algorithm also supports
   specification of one or more trust anchors (by value or reference) as
   an input.  Where the client demands a certification path originating
   with a specific Certification Authority (CA), a single trust anchor
   is specified.  Where the client is willing to accept paths beginning
   with any of several CAs, a set of trust anchors is specified.

   The basic certification path processing algorithm also supports the
   following parameters, which are defined in [PKIX-1], Section 4:

      The usage of the key contained in the certificate (e.g., key
      encipherment, key agreement, signature); and

      Other application-specific purposes for which the certified public
      key may be used.

1.5. Validation Algorithm

The validation algorithm is determined by agreement between the client and the server and is represented as an OID. The algorithm defines the checking that will be performed by the server to determine whether the certificate is valid. A validation algorithm
Top   ToC   RFC5055 - Page 8
   is one of the parameters to a validation policy.  SCVP defines a
   basic validation algorithm that implements the basic path validation
   algorithm as defined in [PKIX-1], and it permits the client to
   request additional information about the certificate to be validated.
   New validation algorithms can be specified that define additional
   checks if needed.  These new validation algorithms may specify
   additional parameters.  The values for these parameters may be
   defined by any validation policy that uses the algorithm or may be
   included by the client in the request.

   Application-specific validation algorithms, in addition to those
   defined in this document, can be defined to meet specific
   requirements not covered by the basic validation algorithm.  The
   validation algorithms documented here should serve as a guide for the
   development of further application-specific validation algorithms.
   For example, a new application-specific validation algorithm might
   require the presence of a particular name form in the subject
   alternative name extension of the certificate.

1.6. Validation Requirements

For a certification path to be considered valid under a particular validation policy, it MUST be a valid certification path as defined in [PKIX-1], and all validation policy constraints that apply to the certification path MUST be verified. Revocation checking is one aspect of certification path validation defined in [PKIX-1]. However, revocation checking is an optional feature in [PKIX-1], and revocation information is distributed in multiple formats. Clients specify in requests whether revocation checking should be performed and whether revocation information should be returned in the response. Servers MUST be capable of indicating the sources of revocation information that they are capable of processing: 1. full CRLs (or full Authority Revocation Lists); 2. OCSP responses, using [OCSP]; 3. delta CRLs; and 4. indirect CRLs.
Top   ToC   RFC5055 - Page 9

2. Protocol Overview

SCVP uses a simple request-response model. That is, the SCVP client creates a request and sends it to the SCVP server, and then the SCVP server creates a single response and sends it to the client. The typical use of SCVP is expected to be over HTTP [HTTP], but it can also be used with email or any other protocol that can transport digitally signed objects. Appendices A and B provide the details necessary to use SCVP with HTTP. SCVP includes two request-response pairs. The primary request- response pair handles certificate validation. The secondary request- response pair is used to determine the list of validation policies and default parameters supported by a specific SCVP server. Section 3 defines the certificate validation request. Section 4 defines the corresponding certificate validation response. Section 5 defines the validation policies request. Section 6 defines the corresponding validation policies response. Appendix A registers MIME types for SCVP requests and responses, and Appendix B describes the use of these MIME types with HTTP.


(page 9 continued on part 2)

Next Section