RFC 5055
Server-Based Certificate Validation Protocol (SCVP)
Pages: 88
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 9
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
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
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
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.....................................861. 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].
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.
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.
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
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.
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)