Internet Draft A. Malpani draft-ietf-pkix-scvp-13.txt Malpani Consulting Services October 2003 R. Housley Expires in six months Vigil Security 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 (2003). All Rights Reserved. Abstract SCVP allows a client to offload certificate handling to a server. The server can provide the client with a variety of valuable information about the certificate, such as whether the certificate is valid, a certification path to a trust anchor, and revocation status. SCVP has many purposes, including simplifying client implementations and allowing companies to centralize trust and policy management. INTERNET DRAFT SCVP June 2003 Table of Contents 1 Introduction.......................................................4 1.1 SCVP overview and requirements..................................4 1.2 Terminology.....................................................5 1.3 Validation Policies.............................................5 2 Protocol Overview..................................................6 3 Validation Request.................................................7 3.1 scvpVersion.....................................................9 3.2 Query...........................................................9 3.2.1 queriedCerts...............................................10 3.2.2 checks.....................................................10 3.2.3 wantBack...................................................11 3.2.4 RequestRefHash.............................................13 3.2.5 IncludePolResponse.........................................13 3.2.6 inhibitPolMap..............................................13 3.2.7 requireExplicitPol.........................................14 3.2.8 ignoreAnyPol...............................................14 3.2.9 serverContextInfo..........................................14 3.2.10 valAlgorithm..............................................15 3.2.10.1 Default Validation Algorithm..........................15 3.2.10.2 Name Validation Algorithm.............................16 3.2.10.3 Name Validation Algorithm Errors......................16 3.2.11 validityTime..............................................17 3.2.12 trustAnchors..............................................18 3.2.13 intermediateCerts.........................................18 3.2.14 revInfos..................................................19 3.2.15 queryExtensions...........................................20 3.3 Requestor......................................................20 3.4 requestNonce...................................................20 3.5 reqExtensions..................................................21 4 Validation Response...............................................21 4.1 scvpVersion....................................................23 4.2 policyID.......................................................23 4.3 producedAt.....................................................24 4.4 responseStatus.................................................24 4.5 requestReference...............................................25 4.5.1 requestHash................................................26 4.5.2 fullRequest................................................26 4.6 Requestor......................................................27 4.7 responder......................................................27 4.8 replyObjects...................................................27 4.8.1 cert.......................................................28 4.8.2 replyStatus................................................28 4.8.3 replyValTime...............................................29 4.8.4 replyChecks................................................29 4.8.5 replyWantBack..............................................31 4.8.6 valAlgorithm...............................................32 4.8.7 nextUpdate.................................................32 4.8.8 certReplyExtensions........................................32 4.9 requestNonce...................................................32 4.10 serverContextInfo.............................................33 Malpani, Housley, & Freeman [Page2] INTERNET DRAFT SCVP June 2003 4.11 respExtensions................................................33 5 SCVP Server certificates..........................................33 5.1 SCVP Server Name...............................................34 5.1.1 SVCP Extended Key Usage....................................34 5.1.2 SCVP Server certificate validation.........................34 6 Server Policies Request...........................................34 7 Validation Policies Response......................................35 7.1 scvpVersion....................................................35 7.2 PolicyID.......................................................35 7.3 thisUpdate.....................................................36 7.4 nextUpdate.....................................................36 7.5 trustAnchors...................................................36 7.6 valAlgorithms..................................................36 7.7 clockSkew......................................................36 8 SCVP Server Relay.................................................36 9 SCVP ASN.1 Module.................................................37 10 Security Considerations..........................................42 11 References.......................................................43 11.1 Normative References..........................................43 11.2 Informative References........................................44 12 Acknowledgments..................................................44 Appendix A -- MIME Registrations....................................45 A.1 application/cv-request.........................................45 A.2 application/cv-response........................................45 A.3 application/cv-policies-request................................46 A.4 application/cv-policies-response...............................47 Appendix B -- SCVP over HTTP........................................48 B.1 SCVP Request...................................................48 Appendix C -- Author Contact Information............................48 Malpani, Housley, & Freeman [Page3] INTERNET DRAFT SCVP June 2003 1 Introduction Certificate validation is complex. If certificate handling is to be widely deployed in a variety of applications and environments, the amount of processing an application needs to perform before it can accept a certificate needs to be reduced. There are a variety of applications that can make use of public key certificates, but these applications are burdened with the overhead of constructing and validating the certification paths. SCVP reduces this overhead for two classes of certificate-using applications. The first class of application wants just two things. First, they want confirmation that the public key belongs to the identity named in the certificate. Second, they want to know if the public key can be used for the intended purpose. The client completely delegates certification path construction and 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 only delegates certification path construction to the SCVP server. 1.1 SCVP overview and requirements The SCVP meets the requirements documented in [RQMTS]. The primary goals of SCVP are to make it easier to deploy PKI- enabled applications and to allow central administration of PKI policies within an organization. SCVP can be used by clients that do much of the certificate processing themselves but simply want an untrusted server to collect information for them. However, when the client has complete trust in the SCVP server, SCVP can be used to delegate the work of certification path construction and validation, and SCVP can be used to ensure that policies are consistently enforced throughout an organization. Untrusted SCVP servers can provide clients the certification paths. They can also provide clients revocation information, such as CRLs and OCSP responses, and the client needs to validate the certification path constructed by the SCVP server. These services can be valuable to clients that do not include the protocols needed to find and download intermediate certificates, CRLs, and OCSP responses. Trusted SCVP servers can perform certification path construction and validation for the client. For a client 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: Malpani, Housley, & Freeman [Page4] INTERNET DRAFT SCVP June 2003 - The client does not want to incur the overhead of including certification path validation software and running it for each certificate it receives. - The client is in an organization or community that wants to centralize its PKI policies. These policies might dictate which trust anchors are used and the types of policy checking that are performed during certification path validation. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [STDWORDS]. 1.3 Validation Policies A validation policy (as defined in RFC 3379 [RQMTS]) specifies the rules to be used by the SCVP server when validated a certificate. In SCVP, the validation policy comprises an algorithm for certificate path processing and the input parameters to the algorithm. The default inputs to the certificate 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 Set of Trust Anchors (by value or by reference) The initial policy set Initial policy mapping setting Initial any-Policy setting Initial explicit policy setting The validation algorithm is determined by agreement between the client and the server, but it MUST be represented as an OBJECT IDENTIFIER. The SCVP server can assign validation algorithm object identifiers which indicate that some predefined settings are used in addition to values provided in the SCVP request. Application-specific validation algorithms in addition to those defined in this document can be defined to meet specific requirements not covered by the default validation algorithm. The validation algorithms documented here should serve as guides for the development of further application-specific validation algorithms. Malpani, Housley, & Freeman [Page5] INTERNET DRAFT SCVP June 2003 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. Applications MAY place additional requirements on the validation algorithm. Revocation checking is one aspect of certification path validation defined in [PKIX-1]. Therefore, the validation policy MUST specify the source of revocation information. Five alternatives are envisioned: 1. full CRLs (or full Authority Revocation Lists) have to be collected; 2. OCSP responses, using [OCSP], have to be collected; 3. delta CRLs and the relevant associated full CRLs (or full Authority Revocation Lists) are to be collected; 4. any available revocation information has to be collected; and 5. no revocation information need be collected. 2 Protocol Overview The SCVP uses a simple request-response model. That is, the SCVP client creates a request and sends it to the SCVP server, and then the SCVP server creates a single response and sends it to the client. The typical use of SCVP is expected to be over HTTP [HTTP], but it can also be used with email. Appendix A and Appendix B provide the details necessary to use SCVP with HTTP. SCVP includes two request-response pairs. The primary request- response pair handles certificate validation. The secondary request- response pair is used to determine the list of validation policies and default parameters supported by a specific SCVP server. Section 3 defines the certificate validation request, and section 4 defines the corresponding response. Section 5 defines the validation policies request, and section 6 defines the corresponding response. Appendix A registers MIME types for SCVP requests and responses, and Appendix B describes the use of these MIME types with HTTP. Malpani, Housley, & Freeman [Page6] INTERNET DRAFT SCVP June 2003 3 Validation Request A SCVP client request to the server MUST be a single CVRequest item. When a SCVPRequest is encapsulated in a MIME body part, application/cv-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 CVRequest encapsulated in a CMS ContentInfo [CMS]. 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-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } The signed request consists of a certValRequest encapsulated in either a SignedData or AuthenticatedData which is in turn encapsulated in a ContentInfo. An overview of this structure is provided below for each of these two cases. Again, many details are not shown, but the way that SCVP makes use of CMS is clearly illustrated. SignedData example: 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 SignerInfo } -- 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 [Page7] INTERNET DRAFT SCVP June 2003 EncapsulatedContentInfo { eContentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) eContent OCTET STRING } -- Contains CVRequest AuthenticatedData example: ContentInfo { contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2) content AuthenticatedData } AuthenticatedData { version CMSVersion, originatorInfo OriginatorInfo, -- Optional recipientInfos RecipientInfos, -- Only SCVP server macAlgorithm MessageAuthenticationCodeAlgorithm, digestAlgorithm DigestAlgorithmIdentifier, -- Optional encapContentInfo EncapsulatedContentInfo, authAttrs AuthAttributes, -- Required mac MessageAuthenticationCode, unauthAttrs UnauthAttributes } -- not used in SCVP EncapsulatedContentInfo { eContentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) eContent OCTET STRING } -- Contains CVRequest All SCVP clients and server MUST support SignedData for signed requests and responses. SCVP clients and servers SHOULD support authenticatedData for authenticated requests and responses. If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response. If a server is responding to an authenticated request, it MUST use an authenticated response or an unsigned error response. The syntax and semantics for signedData, authenticatedData and ContentInfo are defined in [CMS]. The syntax for CVRequest is defined below. The CVRequest item contains the client request. The CVRequest contains the scvpVersion and query items; and the CVRequest MAY also contain the requestor, requestNonce, and reqExtensions items. The CVRequest MUST have the following syntax: CVRequest ::= SEQUENCE { scvpVersion INTEGER, query Query, requestor [0] OCTET STRING OPTIONAL, requestNonce [1] OCTET STRING OPTIONAL, reqExtensions [2] Extensions OPTIONAL } Malpani, Housley, & Freeman [Page8] INTERNET DRAFT SCVP June 2003 Each of the items within the CVRequest are described in the following sections. 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). Future updates to this specification ought to specify other integer values. 3.2 Query The query specifies one or more certificates that are the object of the request; the certificates can be either public key certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain a sequence of one or more certificate references, checks, and wantBack items; and a query MAY also contain valPolicy, validityTime, trustAnchors, intermediateCerts, revInfos, and queryExtensions items. Query MUST have the following syntax: Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, queryExtensions [5] 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 valPolicy, trustAnchors, intermediateCerts, and revInfos items provide context for the client request. The OPTIONAL queryExtensions item provides for future expansion of the query syntax. Malpani, Housley, & Freeman [Page9] INTERNET DRAFT SCVP June 2003 3.2.1 queriedCerts The queriedCerts item, using the CertReference type, identifies the certificate that is the object of the request. The certificate is either a public key certificate or an attribute certificate. The certificate is either directly included or it is referenced. When referenced, a SHA-1 hash value [SHA-1] of the referenced item is included to ensure that the SCVP client and the SCVP server both obtain the same certificate when the referenced certificate is fetched. Certificate references use the ESSCertID type defined in [ESS]. CertReference has the following syntax: CertReference ::= CHOICE { pkc PKCReference, ac ACReference } PKCReference ::= CHOICE { cert [1] Certificate, pkcRef [2] ESSCertID } ACReference ::= CHOICE { attrCert [3] AttributeCertificate, acRef [4] ESSCertID } The ASN.1 definition of Certificate is imported from [PKIX-1]; the definition of AttributeCertificate is imported from [PKIX-AC]; and the definition of ESSCertID is imported from [ESS]. 3.2.2 checks The checks item describes the checking that the SCVP client wants the SCVP server to perform on the certificate(s) in the queriedCerts item. The checks item MUST contain a sequence of object identifiers (OIDs). Each OID tells the SCVP server what checking the client expects the server to perform. For each check specified in the request, the SCVP server MUST perform all of the requested checks, or return an error. Revocation status checking inherently includes certification path construction. Also, building a validated certification path does not imply revocation status checks. A server may still choose to perform revocation status checks when performing path construction, although this information cannot be returned to the client. The checks item uses the CertChecks type, which has the following syntax: CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER A list of OIDs indicates the checking that the client wants the SCVP server to perform on the certificate(s) in the queriedCerts item. Malpani, Housley, & Freeman [Page10] INTERNET DRAFT SCVP June 2003 For public key certificates, OIDs are defined for the following checks: - Build a certification path to a trusted root; - Build a validated certification path to a trusted root; and - Do revocation status checks on the certification path. For attribute certificates, OIDs are defined for the following checks: - Build a certification path to a trusted root for the AC issuer; - Build a validated certification path to a trusted root for the AC issuer; - Do revocation status checks on the certification path for the AC issuer; and - Do revocation status checks on the AC as well as the certification path for the AC issuer. For these purposes, the following OIDs are defined: id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } id-stc-build-status-checked-pkc-path OBJECT IDENTIFIER ::= { id-stc 3 } id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } id-stc-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 6 } id-stc-status-check-ac-and-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 7 } 3.2.3 wantBack The wantBack item describes the kind of information the SCVP client wants from the SCVP server for the certificate(s) in the queriedCerts item. The wantBack item MUST contain a sequence of object identifiers (OIDs). Each OID tells the SCVP server what the client wants to know about the queriedCerts item. For each type of information specified in the request, the server MUST return information regarding its finding (in a successful response). Malpani, Housley, & Freeman [Page11] INTERNET DRAFT SCVP June 2003 For example, a request might include a checks 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 checks item that requests the 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 For public key certificates, the types of information that can be requested are: - Certification path built for the certificate; - Proof of revocation status for each certificate in the certification path; - Status indication; and - Public key from the certificate. For attribute certificates, the types of information that can be requested are: - Certification path built for the AC issuer certificate; - Proof of revocation status for each certificate in the AC issuer certification path; - Proof of revocation status for the attribute certificate; and - Status indication. For these purposes, the following OIDs are defined: id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } Malpani, Housley, & Freeman [Page12] INTERNET DRAFT SCVP June 2003 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 3.2.4 RequestRefHash The requestRefHash controls how the server identifies the corresponding request in the response. By default, the server includes a hash of the request in the response. If the client wants the server to include the full request in the response, RequestRefHash is set to FALSE in the request. The main reason a client would request the server to include the full request in the response is if it wanted to archive the request-response exchange in a single object. That is, the client wants to archive a single object which includes both request and response. SCVP clients and servers MUST support the default behavior. SCVP servers SHOULD support returning the full request. SCVP clients MAY support requesting and processing the full request. 3.2.5 IncludePolResponse The includePolResponse controls whether the responce includes the full PolResponce. By default the server will just put the policyID in the response. If the client wants the full PolResponse item to be included by the server in the CVResponce, then the includePolResponse is set to TRUE. The main reason a client would request the server to include the full PolResponse in the CVResponse is if it wanted to archive the request-response exchange in a single object. That is, the client wants to archive a single object that includes both CVResponse and polResponse. SCVP clients and servers MUST support the default behavior. SVCP server SHOULD support returning the full PolResponse. SCVP clients MAY support requesting and processing the full PolResponse. 3.2.6 inhibitPolMap The inihibitPolMap specifies an input to the certification path validation algorithm, and it controls whether policy mapping is allowed in the certification path validation (see [PKIX-1], section 6.1.1). By default the server allows policy mapping as part of certification path validation. If the client wants the server to inhibit policy mapping, inhibitPolMap is set to TRUE in the request. SCVP clients and servers MUST support the default behavior. SCVP servers SHOULD support inhibiting policy mapping. SCVP clients MAY support inhibiting policy mapping. Malpani, Housley, & Freeman [Page13] INTERNET DRAFT SCVP June 2003 3.2.7 requireExplicitPol The requireExplicitPol specifies an input to the certification path validation algorithm, and it controls whether there must be at least one valid policy in the certificate policies extension (see [PKIX], section 6.1.1). By default the server accepts no policies in the certificate policies extension of valid certificates. If the client wants the server to require at least one policy, requireExplicitPol is set to TRUE in the request. SCVP clients and servers MUST support the default behavior. SCVP server SHOULD support requiring explicit policies. SCVP clients MAY support requiring explicit policies. 3.2.8 ignoreAnyPol The ignoreAnyPol specifies an input to the certification path validation algorithm (see [PKIX], section 6.1.1), and it controls whether the any-policy OID is processed or ignored when evaluating certificate policy. By default the server processes the Any-Policy OID. If the client wants the server to ignore the Any-policy OID, ignoreAnyPol is set to TRUE in the request. SCVP clients and servers MUST support the default behavior. SCVP servers SHOULD support ignoring the Any-Policy OID. SCVP clients MAY support ignoring the Any-Policy OID. 3.2.9 serverContextInfo The serverContextInfo item, if present, contains context from a previous request-response exchange with the same SCVP 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 another one can be found). Contents of the serverContextInfo are opaque to the SCVP 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; and Malpani, Housley, & Freeman [Page14] INTERNET DRAFT SCVP June 2003 - the client's signature on the request. .SCVP servers SHOULD support serverContextInfo. SCVP clients MAY support serverContextInfo 3.2.10 valAlgorithm The valAlgorithm item, defines the validation algorithm to be used by the SCVP server during certificate validation. The value of this item can be determined by agreement between the client and the server, and is represented as an object identifier. The server might want to assign additional object identifiers that indicate that some settings are used in addition to others given in the request. In this way, the validation algorithm object identifier can be a shorthand for some SCVP options, but not others. The valAlgorithm item uses the ValidationAlg type, which has the following syntax: ValidationAlg ::= SEQUENCE { valAlgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valAlgId OPTIONAL } 3.2.10.1 Default Validation Algorithm The client can request the SCVP server's default validation algorithm is used or another algorithm. The object identifier to identify the default validation algorithm is: id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 } When the id-svp-defaultValAlg appears as an valAlgId, the parameters MUST be absent. SCVP servers and clients MUST support the default validation algorithm. SCVP servers and clients MAY support other validation algorithms. The meaning of the default validation algorithm is: - Trust anchors will come from the trustAnchors item. If no certificates are specified in the trustAnchors item, then the SCVP server will use trust anchors of its own choosing. - The acceptable policy set will come from the certPolicies item associated with the selected trust anchor. If no certificate policies are specified in the certPolicies item, then the SCVP server will use any-policy. Malpani, Housley, & Freeman [Page15] INTERNET DRAFT SCVP June 2003 - The SCVP server will check for certificate revocation using CRLs, delta CRLs, OCSP responses, or any other source of revocation information that is available. 3.2.10.2 Name Validation Algorithm The name validation Algorithm allows the client to supply a name to the server along with an application identifier. The application identifier defines the name matching rules use to compare the name supplied in the request with the names in the certificate being validated. id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } When the id-svp- NameValAlg appears as an valAlgId, the parameters MUST use the NameValidationAlg syntax: NameValidationAlg ::= SEQUENCE { KeyPurposeId OBJECT IDENTIFIER, ValidationNames GeneralNames } KeyPurposeId and GeneralNames are defined in [PKIX-1]. If more than one name is supplied in the request, all names MUST be of the same type and be valid according to the name matching rules requested. If the KeyPurposeID supplied in the request is id-kp-serverAuth [PKIX-1], then GeneralNames supplied in the request MUST be a DNS name, and the matching rules to be used are defined in [HTTP-TLS]. If the KeyPurposeID supplied in the request is id-kp-mailProtection [PKIX-1], then GeneralNames supplied in the request MUST be a rfc822 name, and the matching rule MUST be a case insensitive comparison of the whole sting. For example user@example.com matches USER@Example.COM, but not auser@example.com, user@mail.example.com, or user@example1.com 3.2.10.3 Name Validation Algorithm Errors The following errors are defined for the Name Validation Algorithm id-nvae OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 } id-nvae-NameMismatch OBJECT IDENTIFIER ::= { id-nvae 1 } id-nvae-NoCertName OBJECT IDENTIFIER ::= { id-nvae 2 } id-nvae-UnknownPupose OBJECT IDENTIFIER ::= { id-nvae 3 } id-nvae-BadName OBJECT IDENTIFIER ::= { id-nvae 4 } id-nvae-BadNameType OBJECT IDENTIFIER ::= { id-nvae 5 } id-nvae-MixedNames OBJECT IDENTIFIER ::= { id-nvae 6 } Malpani, Housley, & Freeman [Page16] INTERNET DRAFT SCVP June 2003 Name mismatch means the client supplied a name with the validation policy, which the server recognized and the server found corresponding name type in the certificate, but was unable to find a match to the name supplied. For example, the client supplied a DNS name of example1.com, the certificate contained a DNS name of example.com. NoCertName means the client supplied a name with the validation policy, which the server recognized, but the server could not find the corresponding name type in the certificate. For example, the client supplied a DNS name of example1.com, the certificate only contained a rfc822 name of user@example.com. UnknownPupose means the client supplied KeyPurposeID which the server does not recognize. BadName means the client supplied either and empty or malformed name in the request. BadNameType means the client supplied an inappropriate name type for the key purpose. For example, the client specified a key purpose ID of id-kp-serverAuth, and a rfc822 name of user@example.com. MixedNames means the client supplied multiple names in the request of different types. 3.2.11 validityTime The OPTIONAL validityTime item tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validityTime is not present, the server MUST perform the validation using the date and time at which the server processes the request. If the validityTime is present, it MUST be encoded as GeneralizedTime. The validityTime provided MUST be a retrospective time since the server can only perform a validity check using the current time (default) or previous time. A Server can ignore the validityTime provided in the request if the time is within the clock skew of the servers current time. GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when 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 MUST return an error. Malpani, Housley, & Freeman [Page17] INTERNET DRAFT SCVP June 2003 SCVP servers MUST apply a clock skew to the validity time to allow for minor time synchronization errors. The default value is 10 minutes. If the server uses a value other than the default it MUST include the clock skew value in the validation policy response. SCVP servers MUST support using its current time, and SHOULD support the client setting the validityTime in the request. SCVP clients MAY support validityTime. 3.2.12 trustAnchors The OPTIONAL trustAnchors item specifies the trust anchors to be used by the SCVP server. One or more certificate policy MAY be associated with each trust anchor. If a trustAnchors item is present, the server MUST NOT use any certification path trust anchors other than those provided. The TrustAnchors type contains one or more trust anchor specification. A certificate reference can be used to identify the trust anchor by certificate hash and optionally a distinguished name with serial number. Alternatively, trust anchors can be provided directly. The order of trust anchor specifications within the sequence is not important. Any CA certificate can be provided as a trust anchor. The OPTIONAL certPolicies item specifies a list of policy identifiers that the SCVP server MUST use when forming and validating a certification path that terminates at the associated trust anchor. If certPolicies is not specified, then any-policy MUST be used. The trust anchor itself, regardless of its form, MUST NOT be included in any certification path constructed by the SCVP server. TrustAnchors has the following syntax: TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor TrustAnchor ::= SEQUENCE { anchor PKCReference, certPolicies [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL } -- if absent, use any-policy SCVP server MUST support TrustAnchor. SCVP clients SHOULD support trust anchors. 3.2.13 intermediateCerts The OPTIONAL intermediateCerts item helps the SCVP server create valid certification paths. The intermediateCerts item, when present, provides certificates that the server MAY use when forming Malpani, Housley, & Freeman [Page18] INTERNET DRAFT SCVP June 2003 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 considered as valid 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 PKCReference SCVP servers MUST support intermediateCerts. SCVP clients SHOULD support intermediateCerts. 3.2.14 revInfos The OPTIONAL revInfo item specifies revocation information such as CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 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, such as 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. For example, the revocation information might be associated with certificates that the server does not use in certification path building. It is courteous to the SCVP server to separate CRLs and delta CRLs. However, since the two share a common syntax, SCVP servers SHOULD accept delta CRLs even if they are identified as regular CRLs by the SCVP client. CRLs, delta CRLs, and OCSP responses can be provided as revocation information. If needed, additional object identifiers can be assigned for additional revocation information types in the future. The revInfos item uses the RevocationInfos type, which has the following syntax: RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo RevocationInfo ::= CHOICE { crl [0] CertificateList, delta-crl [1] CertificateList, ocsp [2] OCSPResponse, other [3] OtherRevInfo } OtherRevInfo ::= SEQUENCE { Malpani, Housley, & Freeman [Page19] INTERNET DRAFT SCVP June 2003 riType OBJECT IDENTIFIER, riValue ANY DEFINED BY riType } 3.2.15 queryExtensions The OPTIONAL queryExtensions item contains Extensions. If present, each extension in the sequence extends the query. This specification does not define any extensions, the facility is provided to allow future specifications to extend SCVP. The syntax for extensions is imported from [PKIX-1]. The queryExtensions item, when present, MUST contain a sequence of extension items, and each of extension MUST contain extnID, critical, and extnValue items. The extnID item is an identifier for the extension. It contains the object identifier that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An SCVP server MUST reject the query if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. 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 the associated extnID object identifier. 3.3 Requestor The OPTIONAL requestor item is a reference local to the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in the response. The requestor item MUST be an octet string. No provisions are made to ensure uniqueness of the requestor octet string; however, all of the octets MUST have values other than zero. 3.4 requestNonce The OPTIONAL requestNonce item contains an identifier generated by the SCVP 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 from 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, if present, MUST be an octet string that was generated exclusively for this purpose. Malpani, Housley, & Freeman [Page20] INTERNET DRAFT SCVP June 2003 3.5 reqExtensions The OPTIONAL reqExtensions item contains Extensions. If present, each Extension in the sequence extends the request. This specification does not define any extensions, the facility is provided to allow future specifications to extend the SCVP. The syntax for Extensions is imported from [PKIX-1]. The reqExtensions item, when present, MUST contain a sequence of extension items, and each of extension MUST contain extnID, critical, and extnValue items. The extnID item is an identifier for the extension. It contains the object identifier that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An SCVP server MUST reject the query if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. 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 the associated extnID object identifier. 4 Validation Response A SCVP server response to the client MUST be a single CVResponse item. A CVResponse item is carried in an application/cv-response MIME body part. There are two forms of an SCVP response: unsigned and signed. An unsigned response MUST only be generated for an error status. An overview of the structure used for an unsigned response 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-certValResponse, -- (1.2.840.113549.1.9.16.1.11) content CVResponse } The signed response consists of a CVResponse encapsulated in either a SignedData or an AuthenticatedData which is in turn encapsulated in a ContentInfo. An overview of the structure used for a signed response is provided below. As above, many details are not shown, but the way that SCVP makes use of CMS is clearly illustrated. Signed Data Example: ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData } Malpani, Housley, & Freeman [Page21] INTERNET DRAFT SCVP June 2003 SignedData { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates CertificateSet, -- MUST include server cert 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 EncapsulatedContentInfo { eContentType id-ct-scvp-psResponse, -- (1.2.840.113549.1.9.16.1.11) eContent OCTET STRING } -- Contains CVResponse AuthenticatedData Example: ContentInfo { contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2) content AuthenticatedData } AuthenticatedData ::= SEQUENCE { version CMSVersion, originatorInfo OriginatorInfo, -- Optional recipientInfos RecipientInfos, -- Only for SCVP client macAlgorithm MessageAuthenticationCodeAlgorithm, digestAlgorithm DigestAlgorithmIdentifier, -- Optional encapContentInfo EncapsulatedContentInfo, authAttrs AuthAttributes, -- Required mac MessageAuthenticationCode, unauthAttrs UnauthAttributes } -- Not used in SCVP EncapsulatedContentInfo { eContentType id-ct-scvp-psResponse, -- (1.2.840.113549.1.9.16.1.11) eContent OCTET STRING } -- Contains CVResponse The SCVP server MUST include its own certificate in the certificates field within SignedData. The SCVP server MUST include its own certificate in the certificates field within AuthenticatedData if the HMAC key is derived using a public key from a certificate. Other certificates can also be included. The Malpani, Housley, & Freeman [Page22] INTERNET DRAFT SCVP June 2003 SCVP server MAY also provide one or more CRLs in the crls field within SignedData. The signedAttrs within SignerInfo MUST include the content-type and message-digest attributes defined in [CMS] as well as the SigningCertificate attribute as defined in [ESS]. Within the SigningCertificate attribute, the first certificate identified in the sequence of certificate identifiers MUST be the certificate of the SCVP server. The inclusion of other certificate identifiers in the SigningCertificate attribute is OPTIONAL. The inclusion of policies in the SigningCertificate attribute is also OPTIONAL. The policies item in the SigningCertificate attribute SHALL not be present. The value of the message-digest attribute in the signedAttrs within SignerInfo MAY be used as an identifier of the response generated by the SCVP server. The CVResponse item contains the server response. The CVResponse MUST contain the scvpVersion, producedAt, responseStatus, and requestRef items. The CVResponse MAY also contain the 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 CVResponse MUST have the following syntax: CVResponse ::= SEQUENCE { scvpVersion INTEGER, policyID 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, polResponse [6] OCTET STRING OPTIONAL, respExtensions [7] Extensions OPTIONAL } 4.1 scvpVersion The syntax and semantics of the scvpVersion item is described in section 3.1. 4.2 policyID Malpani, Housley, & Freeman [Page23] INTERNET DRAFT SCVP June 2003 The policy ID in effet when the server processed the request. See section 7.2 for details. 4.3 producedAt The producedAt item tells the date and time at which the SCVP server generated the response. The producedAt item represents the date and time in UTC, using the GeneralizedTime type and is independent of the validation time use. GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu) and MUST be interpreted as defined in section 3.2.11 4.4 responseStatus The responseStatus item gives status information to the SCVP 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 assistance. 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), internalError (12), badStructure (20), unsupportedVersion (21), abortUnrecognizedItems (22), unrecognizedSigKey (23), badSignature (24), unableToDecode (25), notAuthorized (26), unsupportedChecks (27), unsupportedWantBacks (28), unsupportedSignature (29), invalidSignature (30), relayingLoop (40), fullRequestRefUnsuported (51}, fullPolRequestUnsuported (52), Malpani, Housley, & Freeman [Page24] INTERNET DRAFT SCVP June 2003 inhibitPolMapUnsuported (53), requireExpPolUnsuported (54), ignoreAnyPolUnsuported (55), validityTimeUnsuported (56) } The SCVPStatusCode values have the following meaning: 0 The request was fully processed 1 The request included some unrecognized items; however, processing was able to continue ignoring them 10 Too busy; try again later 12 Internal server error occurred 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, and the server was not able to continue processing 23 The key given in the RequestSignature is not recognized 24 The signature or MAC did not match the body of the request 25 The encoding was not understood 26 The request was not authorized 27 The request included unsupported checks items, and the server was not able to continue processing 28 The request included unsupported want back items, and the server was not able to continue processing 29 The server does not support the signature or MAC algorithm used by the client to sign the request 30 The server could not validate the client's signature or MAC on the request 40 The request was previously relayed by the same server 50 The request contained an unrecognized validation algorithm 51 The server does not returning the full request in the response 52 The server does not returning the full policy responce 53 The server does not support inhibiting policy mapping 54 The server does not support requiring explicit policy 55 The server does not support ignoring the any policy OID 56 The server only validates requests using current time Status codes 0-9 are reserved for codes where the request was processed by the server and therefore MUST be sent in a signed response. Status codes 10 and above indicate an error and MUST therefore be sent in an unsigned response. 4.5 requestReference The requestRef allows the SCVP server to identify the request that corresponds to this response. It associates the response to a particular request using either a hash of the request or a copy of CVRequest from the request. The hash is calculated as described in [CMS] for signedData and authenticatedData. That is, it covers the encapsulated content and authenticated attributes but not the unauthenticated attributes. Malpani, Housley, & Freeman [Page25] INTERNET DRAFT SCVP June 2003 The requestRef item does not provide authentication, but the requestRef does allow the client to determine that the request was not maliciously modified. The requestRef item allows the client to associate a response with a request. The requestNonce provides an alternative mechanism for matching requests and responses if the client has selected to include a full responce. 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 [1] HashValue, -- hash of CVRequest fullRequest [2] CVRequest } 4.5.1 requestHash The requestHash item is the hash of the CVRequest. 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. The requestNonce provides an alternative mechanism for matching requests and responses. The requestHash item uses the HashValue type, which has the following syntax: HashValue ::= SEQUENCE { algorithm AlgorithmIdentifier DEFAULT { sha-1 }, value OCTET STRING } sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It is repeated here for convenience. 4.5.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 CVRequest type. The syntax and semantics of the PSRequest type are described in section 3. Malpani, Housley, & Freeman [Page26] INTERNET DRAFT SCVP June 2003 4.6 Requestor The OPTIONAL requestor item is used to identify the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in the response. The requestor item MUST be an octet string. No provisions are made to ensure uniqueness of the requestor octet string; however, all of the octets MUST have values other than zero. 4.7 responder The OPTIONAL responder item is used to identify the server. The value chosen is only of local significance to the SCVP server. The responder items MUST be included if the request included a requestor item. The responder item MUST be an octet string. No provisions are made to ensure uniqueness of the requestor octet string; however, all of the octets MUST have values other than zero. 4.8 replyObjects The replyObjects item returns requested objects to the SCVP client, each of which tells the client about a single certificate from the request. The replyObjects item MUST be present in the response, unless the response is reporting an error. The CertReply item MUST contain cert, replyStatus, replyValTime, replyChecks, replyWantBack, and valPolicy items; and the CertReply item MAY contain the nextUpdate and certReplyExtensions optional items. A non-error response MUST contain one CertReply for each Query item in the request. The order is important. The first CertReply in the sequence MUST correspond to the first Query item in the request; the second CertReply in the sequence MUST correspond to the second Query item in the request; and so on. The checks item in the request determines the content of the replyChecks item in the response. The wantBack item in the request determines the content of the replyWantBacks item in the response. The queryExtensions items in the request controls the absence or the presence and content of the certReplyExtensions item in the response. The replyObjects item uses the ReplyObjects type, which has the following syntax: ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply CertReply ::= SEQUENCE { cert CertReference, Malpani, Housley, & Freeman [Page27] INTERNET DRAFT SCVP June 2003 replyStatus ReplyStatus, replyValTime GeneralizedTime, replyChecks ReplyChecks, replyWantBacks ReplyWantBacks, valAlg ValidationAlg, nextUpdate [1] GeneralizedTime OPTIONAL, certReplyExtensions [2] Extensions OPTIONAL } 4.8.1 cert The cert item contains either the public key certificate or the attribute certificate or a reference to the certificate about which the client is requesting information. The ASN.1 definition of Certificate is imported from [PKIX-1]; and the definition of AttributeCertificate is imported from [PKIX-AC]. 4.8.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), unrecognizedCheck (1), unrecognizedWantBack (2), malformedPKC (3), malformedAC (4), unrecognizedCertPolicy (5), unrecognizedValPolicy (6), unrecognizedExtension (7), unavailableValidityTime (8), referenceCertHashFail (9), certPathConstructFail (10), certPathNotValid (11), certPathNotValidNow (12) } The meaning of the various ReplyStatus values are: 0 Success: a definitive answer follows 1 Failure: an OID in the check item is not recognized 2 Failure: an OID in the wantBack item is not recognized 3 Failure: the public key certificate was malformed 4 Failure: the attribute certificate was malformed 5 Failure: the certificate policy OID is not recognized 6 Failure: the validation policy OID is not recognized Malpani, Housley, & Freeman [Page28] INTERNET DRAFT SCVP June 2003 7 Failure: the extension OID is not recognized 8 Failure: historical data for the requested validity time is not available 9 Failure: the referenced certificate did not match the hash value provided 10 Failure: no certification path could be constructed 11 Failure: the constructed certification path is invalid 12 Failure: the constructed certification path is invalid, but a query at a later time may be successful Codes 3 and 4 are used to tell the client that the request was properly formed, but the certificate in question was not. This is especially useful to clients that do not parse certificates. 4.8.3 replyValTime The replyValTime item tells the time at which the information in the CertReply was correct. The replyValTime item represents the date and time in UTC, using GeneralizedTime type. The encoding rules for GeneralizedTime in section 3.2.11 MUST be used. Within the request, the optional validityTime item tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validityTime is not present, the server MUST respond as if the client provided the date and time at which the server processes the request. The information in the CertReply item MUST be formatted as if the server created this portion of response at the time indicated in the validityTime item of the query. However, if the server does not have appropriate historical information, the server MAY either return an error or return information for a later time. 4.8.4 replyChecks The replyChecks contains the responses to the checks item in the query. The replyChecks item repeats the object identifier (OID) from the query and an integer. The value of the integer indicates whether the requested check was successful. The OIDs in the checks item of the query are used to identify the corresponding replyChecks values. The OIDs in the replyChecks item MUST match the OIDs in the checks item in the request. The replyChecks item uses the ReplyChecks type, which has the following syntax: ReplyChecks ::= SEQUENCE OF ReplyCheck ReplyCheck ::= SEQUENCE { check OBJECT IDENTIFIER, status INTEGER } Malpani, Housley, & Freeman [Page29] INTERNET DRAFT SCVP June 2003 The status value for public key certification path building to a trusted root, { id-stc 1 }, can be one of the following: 0: Built a path 1: Could not build a path The status value for public key certification path building to a trusted root along with simple validation processing, { id-stc 2 }, can be one of the following: 0: Valid 1: Not valid The status value for public key certification path building to a trusted root along with complete status checking, { id-stc 3 }, can be one of the following: 0: Good 1: Revoked 2: Unknown 3: Unavailable The status value for AC issuer certification path building to a trusted root, { id-stc 4 }, can be one of the following: 0: Built a path 1: Could not build a path The status value for AC issuer certification path building to a trusted root along with simple validation processing, { id-stc 5 }, can be one of the following: 0: Valid 1: Not valid The status value for AC issuer certification path building to a trusted root along with complete status checking, { id-stc 6 }, can be one of the following: 0: Good 1: Revoked 2: Unknown 3: Unavailable The status value for revocation status checking of an AC as well as AC issuer certification path building to a trusted root along with complete status checking, { id-stc 7 }, can be one of the following: 0: Good 1: Revoked 2: Unknown Malpani, Housley, & Freeman [Page30] INTERNET DRAFT SCVP June 2003 3: Unavailable 4.8.5 replyWantBack The replyWantBack contains the responses to the wantBack item in the request. The replyWantBack item includes the object identifier (OID) from the wantBack item in the request and an octet string. Within the octet string is the requested value. The 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 replyWantBack item uses the ReplyWantBack type, which has the following syntax: ReplyWantBacks ::= SEQUENCE OF ReplyWantBack ReplyWantBack::= SEQUENCE { wb OBJECT IDENTIFIER, value OCTET STRING } The octet string value for the certification path used to verify the certificate in the request, { id-swb 1 }, contains the CertBundle type. The syntax and semantics of the CertBundle type are described in section 3.2.7. The octet string value for the proof of revocation status, { id-swb 2 }, contains the RevocationInfo type. The syntax and semantics of the RevocationInfo type are described in section 3.2.9. The octet string value for the public key certificate status, { id- swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if the certificate is valid, and the value will be FALSE if the certificate is not valid. The octet string value for the public key information, { id-swb 4 }, contains the SubjectPublicKeyInfo type. The syntax and semantics of the SubjectPublicKeyInfo type are described in [PKIX-1]. The octet string value for the AC issuer certification path used to verify the certificate in the request, { id-swb 5 }, contains the CertBundle type. The syntax and semantics of the CertBundle type are described in section 3.2.7. The octet string value for the proof of revocation status of the AC issuer certification path, { id-swb 6 }, contains the RevocationInfo type. The syntax and semantics of the RevocationInfo type are described in section 3.2.9. The octet string value for the proof of revocation status of the attribute certificate, { id-swb 7 }, contains the RevocationInfo Malpani, Housley, & Freeman [Page31] INTERNET DRAFT SCVP June 2003 type. The syntax and semantics of the RevocationInfo type are described in section 3.2.9. The octet string value for the attribute certificate status, { id- swb 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if the certificate is valid, and the value will be FALSE if the certificate is not valid. 4.8.6 valAlgorithm The valAlgorithm item indicates the validation algorithm used by the SCVP server. The server MUST include the validation algorithm that was used. The syntax and semantics of the valAlgorithm item are descried in section 3.2.10 4.8.7 nextUpdate The nextUpdate item tells the time at which the server expects a refresh of information regarding the validity of the certificate to become available. The nextUpdate is especially interesting if the certificate revocation status information is not available or the certificate is suspended. The nextUpdate item represents the date and time in UTC, using the GeneralizedTime type. The encoding rules for GeneralizedTime in section 3.2.11 MUST be used. 4.8.8 certReplyExtensions The certReplyExtensions contains the responses to the queryExtension item in the request. The singleReplyExtensions item uses the Extensions type defined in [PKIX-1]. The object identifiers (OIDs) in the queryExtension item in the request are used to identify the corresponding reply value. The certReplyExtensions 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 OID that names the extension, and it MUST match one of the OIDs in the queryExtension item in the request. The critical item is a BOOLEAN, and it MUST be set to FALSE. The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, and identified by extnID. 4.9 requestNonce The requestNonce optional item contains an identifier generated by the client for the request. If the client includes a requestNonce Malpani, Housley, & Freeman [Page32] INTERNET DRAFT SCVP June 2003 value in the request, then the server MUST return the same value in the response. The requestNonce item uses the octet string type. 4.10 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 certification path retuned, it can make a new query and pass along this context information. Section 3.2.4 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 another one can be found). 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. However, 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.11 respExtensions The respExtensions item MAY contain Extensions. If present, each Extension in the sequence extends the request. This specification does not define any extensions, the facility is provided to allow future specifications to extend the SCVP. The syntax for Extensions is imported from [PKIX-1]. The respExtensions 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) that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An SCVP client MUST reject the response if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, and identified by extnID. 5 SCVP Server certificates Malpani, Housley, & Freeman [Page33] INTERNET DRAFT SCVP June 2003 The SCVP server MUST have a single digital signature certificae in use at any one time and that certificaet is MUST be used to sign the validation policy responces. The digital signature certificate MUST have either the digital signatue or the non-repudiation bits set or both in the key usage extesnion of the certificate [PKIX-1 section 4.2.1.3]. A SCVP server MUST have a single key agrement certificate in use at any one time if the server suports authenticatedData signed requests. 5.1 SCVP Server Name 5.1.1 SVCP Extended Key Usage It is necessary to ensure that the entity signing the validation response has been authorized to do so. SCVP response signing delegation SHALL be designated by the inclusion of a key pupose OID in an extendedKeyUsage certificate extension in the SCVP Server certificate. 5.1.2 SCVP Server certificate validation SCVP clients MUST be capable of detecting and enforcing use of the key purpose value as described above. They MAY provide a means of locally configuring one or more SCVP servers, and specifying the set SCVP servers which are trusted. They MUST reject the response if the certificate required to validate the signature on the validation response fails to any one of the following criteria: - Matches a local configuration of SCVP server for the certificate in question; or - Includes a value of id-?? in an ExtendedKeyUsage extension. 6 Server Policies Request A SCVP client uses the PolRequest item to request the list of validation policies supported by the SCVP server. When a PolRequest is encapsulated in a MIME body part, it MUST be carried in an application/cv-policies-request MIME body part. The request consists of a PolRequest encapsulated in a ContentInfo. The request is not signed by the client. ContentInfo { contentType id-ct-scvp-valPolRequest, -- (1.2.840.113549.1.9.16.1.12) content PolRequest } The PolRequest type has the following syntax: Malpani, Housley, & Freeman [Page34] INTERNET DRAFT SCVP June 2003 PolRequest ::= SEQUENCE { scvpVersion INTEGER } The scvpVersion item is described in section 3.1. 7 Validation Policies Response In response to a PolRequest, the SCVP server provides a PolResponse. The polResponce is not unique to any PolRequest, so may be reused by the server in response to multiple PolRequests. The PolResponce also has an indecation of how frequently the PolResponce may be reissued. When a PolResponse is encapsulated in a MIME body part, it MUST be carried in an application/cv-policies-response MIME body part. The response consists of a PolResponse encapsulated in a ContentInfo. The response MUST be signed by the server using its digital signature certificate. ContentInfo { contentType id-ct-scvp-PolResponse, -- (1.2.840.113549.1.9.16.1.13) content PolResponse } The PolResponse type has the following syntax: PoliciesResponse ::= SEQUENCE { scvpVersion INTEGER, DefaultPolicyID INTEGER, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, trustAnchors TrustAnchors, valAlgorithms SEQUENCE OF OBJECT IDENTIFIER, authPolicies SEQUENCE OF OBJECT IDENTIFIER, clockSkew INTEGER OPTIONAL, authDataCert Certificate OPTIONAL } 7.1 scvpVersion The scvpVersion item is described in section 3.1. 7.2 PolicyID An integer which uniquely represents the version of the default validation policy as represented by the trustAnchors, valAlgorithms, authPolicies, clock skew and authDataCerts. If any of these values change, the server MUST create a new PolResponce with a new PolicyID. If the policy and therefore the policyID has not changed, then the server may reused PolicyID across multiple PolResponce messages. However if the server having changed the policy, then Malpani, Housley, & Freeman [Page35] INTERNET DRAFT SCVP June 2003 reverts to an earlier policy, the server MUST NOT revert the policy ID as well, but select another unique value. 7.3 thisUpdate This field indicates the signing date & time of this policy response. Since the polResponse is not bound to a specific request. A SCVP server may periodically generate the response and use the same polResponce for multiple requests. GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) and interpreted as defined in section 3.2.11. 7.4 nextUpdate This field indicates the expected publication date & time of the next policy response. GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) and interpreted as defined in section 3.2.11. 7.5 trustAnchors The trustAnchors item specifies the trust anchors that the SCVP server will use if the client omits the trustAnchours from the request. 7.6 valAlgorithms The valAlgorithms item contains a sequence of object identifiers (OIDs). Each OID identifies a single validation algorithm supported by the server. 7.7 clockSkew The number of minures the server will allow for clock skew. If absent the server MUST use the default valie of 10 minutes. 8 SCVP Server Relay In some network environments, especially ones that include firewalls, an SCVP server might not be able to obtain all of the information that it needs to process a request. However, the server might be configured to use the services of one or more other SCVP servers to fulfill all requests. In such cases, the SCVP client is unaware that the initial SCVP server is using the services of other SCVP servers. The initial SCVP server acts as a client to another SCVP server. Unlike the original client, the SCVP server is expected to have moderate computing and memory resources. This section describes SCVP server-to-SCVP server exchanges. This section does not impose any requirements on SCVP clients that are not also SCVP servers. Further, this section does Malpani, Housley, & Freeman [Page36] INTERNET DRAFT SCVP June 2003 not impose any requirements on SCVP servers that do not relay requests to other SCVP servers. When one SCVP server relays a request to another server, in an incorrectly configured system of servers, it is possible that the same request will be relayed back again. Any SCVP server that relays requests MUST implement the conventions described in this section to detect and break loops. When an SCVP server relays a request, the request MUST include the requestor item. If the request to be relayed already contains a requestor item, then server-generated request MUST contain a requestor item constructed from this value followed by a zero octet followed by the identifier of the SCVP server. If the request to be relayed does not contain a requestor item, then server-generated request MUST contain only identifier of the SCVP server. When an SVCP server receives a request that contains a requestor item, the server MUST check for its own identifier. The identifier could be located at the beginning of the octet string followed by a zero octet, or it could be located between two zero octets. If the server discovers its own identifier in the requestor item, it MUST respond with an error, setting the responseStatus to 40. 9 SCVP ASN.1 Module This section defines the syntax for SCVP request-response pairs. The semantics for the messages are defined in sections 3, 4, 5, and 6. The SCVP ASN.1 module follows. SCVP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 21 } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS AlgorithmIdentifier, Certificate, Extensions, GeneralNames, SubjectPublicKeyInfo, UTF8String, CertificateList FROM PKIX1Explicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 18 } AttributeCertificate FROM PKIXAttributeCertificate -- RFC 3281 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 12 } ESSCertID FROM ExtendedSecurityServices -- RFC 2634 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) Malpani, Housley, & Freeman [Page37] INTERNET DRAFT SCVP June 2003 pkcs-9(9) smime(16) modules(0) 2 } ; -- SCVP Certificate Validation Request id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) 1 } id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } CVRequest ::= SEQUENCE { scvpVersion INTEGER, query Query, requestor [0] OCTET STRING OPTIONAL, requestNonce [1] OCTET STRING OPTIONAL, reqExtensions [2] Extensions OPTIONAL } Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, queryExtensions [5] Extensions OPTIONAL} CertReference::= CHOICE { pkc PKCReference, ac ACReference } PKCReference ::= CHOICE { cert [1] Certificate, pkcRef [2] ESSCertID } ACReference ::= CHOICE { attrCert [3] AttributeCertificate, acRef [4] ESSCertID } CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER ValidationAlg ::= SEQUENCE { valAlgId OBJECT IDENTIFIER, Malpani, Housley, & Freeman [Page38] INTERNET DRAFT SCVP June 2003 parameters ANY DEFINED BY valAlgId OPTIONAL } NameValidationAlg ::= SEQUENCE { KeyPurposeId OBJECT IDENTIFIER, ValidationName GeneralNames } TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor TrustAnchor ::= SEQUENCE { anchor PKCReference, certPolicies [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL } -- if absent, use any-policy CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo RevocationInfo ::= CHOICE { crl [0] CertificateList, delta-crl [1] CertificateList, ocsp [2] OCSPResponse, other [3] OtherRevInfo } OtherRevInfo ::= SEQUENCE { retype OBJECT IDENTIFIER, revalue ANY DEFINED BY retype } -- SCVP Certificate Validation Request id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } CVResponse ::= SEQUENCE { scvpVersion INTEGER, policyID 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, polResponse [6] OCTET STRING OPTIONAL, respExtensions [7] Extensions OPTIONAL } ResponseStatus ::= SEQUENCE { statusCode SCVPStatusCode, errorMessage [0] UTF8String OPTIONAL } SCVPStatusCode ::= ENUMERATED { okay (0), Malpani, Housley, & Freeman [Page39] INTERNET DRAFT SCVP June 2003 skipUnrecognizedItems (1), tooBusy (10), internalError (12), badStructure (20), unsupportedVersion (21), abortUnrecognizedItems (22), unrecognizedSigKey (23), badSignature (24), unableToDecode (25), notAuthorized (26), unsupportedChecks (27), unsupportedWantBacks (28), unsupportedSignature (29), invalidSignature (30), relayingLoop (40), unrecognisedValidationAlg (50), FullRequestRefUnsuported (51}, FullPolRequestUnsuported (52), InhibitPolMapUnsuported (53), RequireExpPolUnsuported (54), IgnoreAnyPolUnsuported (55), validityTimeUnsuported (56) } RequestReference ::= CHOICE { requestHash [1] HashValue, -- hash of CVRequest fullRequest [2] CVRequest } HashValue ::= SEQUENCE { algorithm AlgorithmIdentifier DEFAULT { sha-1 }, value OCTET STRING } sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply CertReply ::= SEQUENCE { cert ReplyCertificate, replyStatus ReplyStatus, replyValTime GeneralizedTime, replyChecks ReplyChecks, replyWantBacks ReplyWantBacks, valAlg ValidationAlg, nextUpdate [1] GeneralizedTime OPTIONAL, certReplyExtensions [2] Extensions OPTIONAL } ReplyCertificate ::= CHOICE { pkc [1] Certificate, ac [2] AttributeCertificate } Malpani, Housley, & Freeman [Page40] INTERNET DRAFT SCVP June 2003 ReplyStatus ::= ENUMERATED { success (0), unrecognizedCheck (1), unrecognizedWantBack (2), malformedPKC (3), malformedAC (4), unrecognizedCertPolicy (5), unrecognizedValPolicy (6), unrecognizedExtension (7), unavailableValidityTime (8), referenceCertHashFail (9), certPathConstructFail (10), certPathNotValid (11), certPathNotValidNow (12) } ReplyChecks ::= SEQUENCE OF ReplyCheck ReplyCheck ::= SEQUENCE { check OBJECT IDENTIFIER, status INTEGER } ReplyWantBacks ::= SEQUENCE OF ReplyWantBack ReplyWantBack::= SEQUENCE { wb OBJECT IDENTIFIER, value OCTET STRING } -- SCVP Validation Policies Request id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } VPRequest ::= SEQUENCE { scvpVersion INTEGER } -- SCVP Validation Policies Response id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } ValPoliciesResponse ::= SEQUENCE { scvpVersion INTEGER, DefaultPolicyID INTEGER, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, trustAnchors TrustAnchors, valAlgorithms SEQUENCE OF OBJECT IDENTIFIER, authPolicies SEQUENCE OF OBJECT IDENTIFIER, clockSkew INTEGER OPTIONAL, authDataCert Certificate OPTIONAL } -- SCVP Check Identifiers id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) Malpani, Housley, & Freeman [Page41] INTERNET DRAFT SCVP June 2003 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } id-stc-build-status-checked-pkc-path OBJECT IDENTIFIER ::= { id-stc 3 } id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } id-stc-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 6 } id-stc-status-check-ac-and-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 7 } -- SCVP WantBack Identifiers id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } -- SCVP Validation Policy Identifiers 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 } END 10 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 requestRef item in the response and ensure that it matches their original request. Requests contain a lot of Malpani, Housley, & Freeman [Page42] INTERNET DRAFT SCVP June 2003 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 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 response matches the value in the request, an attacker can replay previous responses from the SCVP server. If the server does not require some sort of authorization (such as signed requests), an attacker can get the server to respond 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 a different set of validation policies than it actually does. This could result in the client requesting validation based on a policy the server does not support or lead the client using a less desirable policy. SCVP does not include any confidentiality mechanisms. If confidentiality is needed, it can be achieved with a lower-layer security protocol. 11 References Normative and informative references are provided. 11.1 Normative References [STDWORDS] 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. Malpani, Housley, & Freeman [Page43] INTERNET DRAFT SCVP June 2003 [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-1] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. [PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, 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. [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 11.2 Informative References [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [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", RFC 3379, September 2002. 12 Acknowledgments The lively debate in the PKIX Working Group has made a significant impact on this protocol. Denis Pinkas and Phillip Hallam-Baker suggested additional requirements for the protocol. Mike Myers Malpani, Housley, & Freeman [Page44] INTERNET DRAFT SCVP June 2003 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, Peter Sylvester, and Yuriy Dzambasow provided good input, greatly improving this document. Appendix A -- MIME Registrations Four MIME type registrations are provided in this appendix. A.1 application/cv-request To: ietf-types@iana.org Subject: Registration of MIME media type application/cv-request MIME media type name: application MIME subtype name: cv-request Required parameters: format Optional parameters: None 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/cv-response To: ietf-types@iana.org Subject: Registration of MIME media type application/cv-response Malpani, Housley, & Freeman [Page45] INTERNET DRAFT SCVP June 2003 MIME media type name: application MIME subtype name: cv-response Required parameters: format Optional parameters: None Encoding considerations: binary Security considerations: Unless reporting an error, the response is 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 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/cv-policies-request To: ietf-types@iana.org Subject: Registration of MIME media type application/cv-policies- request MIME media type name: application MIME subtype name: cv-policies-request Required parameters: format Optional parameters: None Encoding considerations: binary Security considerations: Carries a request for information. Malpani, Housley, & Freeman [Page46] INTERNET DRAFT SCVP June 2003 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 Intended usage: COMMON Author/Change controller: Ambarish Malpani A.4 application/cv-policies-response To: ietf-types@iana.org Subject: Registration of MIME media type application/cv-policies- response MIME media type name: application MIME subtype name: cv-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 Malpani, Housley, & Freeman [Page47] INTERNET DRAFT SCVP June 2003 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. 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 CVRequest. 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 CVResponse. 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 Malpani Consulting Services Malpani, Housley, & Freeman [Page48] INTERNET DRAFT SCVP June 2003 ambarish@malpani.biz Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA housley@Vigilsec.com Trevor Freeman Microsoft Corporation, One Microsoft way. Redmond, WA 98052 USA. trevorf@microsoft.com 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 [Page49]