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) }; 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", . 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 Intended usage: COMMON Author/Change controller: Ambarish Malpani 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 Intended usage: COMMON Author/Change controller: Ambarish Malpani 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 Malpani, Housley, & Freeman [Page 29] INTERNET DRAFT SCVP October 2002 Intended usage: COMMON Author/Change controller: Ambarish Malpani 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 Intended usage: COMMON Author/Change controller: Ambarish Malpani 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]