Internet Draft Ambarish Malpani draft-ietf-pkix-scvp-01.txt ValiCert August 9, 1999 Paul Hoffman Expires in six months VPN Consortium 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. Abstract The SCVP protocol allows a client to offload certificate handling to a server. The server can give a variety of valuable information about the certificate, such as whether or not the certificate is valid, a chain to a trusted root, and so on. 1. Introduction Certificate validation is a difficult problem. 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 must be reduced. There are a variety of applications that can use public key certificates but are burdened by the overhead of validating the certificates when all the application really wants is the public key and name from the certificate, and a determination of whether or not the certificate may be used for a particular purpose. There are other applications that can perform certificate path validation but have no reliable method of obtaining a current chain to a trusted root. 1.1 SCVP overview and requirements The primary goals of SCVP are to make it easier for applications to deploy systems using a PKI and to allow centralization of administering PKI policies. Parts of SCVP can be used by clients that do much of the PKI processing themselves and simply want a useful but untrusted server that will collect information for them. Other parts can be used by clients that have complete trust in the server to both offload the work of certificate validation and to ensure that policies are enforced in a consistent fashion across an enterprise. Untrusted SCVP servers can give client the certificate chains needed for path validation. They can also give clients revocation information such as CRLs and OCSP responses that the client can use in the client's path validation. These services can be valuable to client systems that do not include the protocols needed to find and download all of the intermediate certificates, CRLs, and OCSP responses needed for the client to perform complete path validation. Trusted SCVP servers can perform full certificate validation for the client. If a client uses these services, it inherently trusts the SCVP server as much as it would its own path validation software (if it contained such software). There are two main reasons that a client may want to trust such an SCVP server: - The client does not want to incur the overhead of including path validation software and running it for each certificate it receives. - The client is in an enterprise that wants to centralize its PKI validation policies, such as which root certificates are trusted and which types of policy checking are performed during path validation. 1.2 Terminology Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are used in capital letters. This conforms to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help implementors achieve interoperability. 1.3 Open Issues The following is a list of issues that were raised on earlier versions of this document that have not been fully dealt with here. Comments on these issues are particularly welcome. - CertBundle items can have certificates represented either in their entirety or as a hash of the cert. We included cert hashes as a way of making the request and responses smaller. However, each side of the request and response can only use a cert hash if it is sure that the other side already has the cert. This preexisting knowledge can reduce the size of the messages but can also cause problems if the two sides are not completely correct about what the other side knows. The CertBundle item is now only used in TrustedRoots, RequestSignature, ResponseSignature, and ReplyWantBack items. Is it OK to use hashes in all these items? Can we use hashes safely in other places which now require full certificates? - Extensions can be marked as critical. The usefulness and problems of criticality have been long debated and there has not been a great deal of consensus. In SCVP, marking a request extension as critical says to the server "don't give me an answer unless you understand this extension", and marking a response as critical says "don't use this response unless you understand this extension". Without the critical bit in the extensions, either the semantics of extensions would have to be changed to essentially say "all extensions are critical" (which is overkill for some extensions that might really be optional), or the semantics would have to be changed to say "you can never rely on the other party understanding an extension", which would limit the usefulness of some extensions. - In this version of the spec, all responses must be signed. In the previous version, signing was optional if the protocol was being used in an otherwise secure environment; this was criticized as being too hard to enforce. However, there are many responses on which a signature might not be needed and a server could be more efficient if it did not need to sign those responses. One way around this is to go back to an optional response signature and carefully list the places that the signature is and is not needed. Another is to create a NULL signature algorithm so that "signing" takes almost no effort. 2. Protocol The SCVP protocol uses a simple request-response model. That is, a SCVP client creates a single request and sends it to the server; the server creates a single response and sends it to the client. Typical use of SCVP is expected to be over HTTP, and possibly email. This document registers MIME types for SCVP requests and responses. 3. Requests A SCVP client's request to the server MUST be a single FullRequest item. The FullRequest item contains the entire request. A FullRequest item is carried in an application/scvp-request MIME body part. 3.1 FullRequest The FullRequest item encapsulates the client's request. The FullRequest item contains a TBSRequest item, an RequestHash item, and an optional RequestSignature item. The RequestHash and the RequestSignature items are performed over the TBSRequest item. 3.2 TBSRequest The TBSRequest item contains the part of the client's request that is hashed by the RequestHash item and optionally signed by the RequestSignature item. The TBSRequest item contains a Version item, a Query item, a TypesOfCheck item, and a WantBack item. It can also contain an optional RequestNonce item and an optional Extensions item. In this specification, the item(s) in the Query item are certificates. The TypesOfCheck item tells the server what types of checking it should do on the item(s) in the Query item. The WantBack item tells the server what the client wants to know about the item(s). Extensions in the TBSRequest item are used to extend the request, such as to request a different type of item. 3.3 Version The Version item tells the version of SCVP used in a request or a response. The value of the Version item for this specification is 1. 3.4 Query The Query item specifies the object of the request. One type of object is defined in this specification: CertsQuery. The CertsQuery is a request for information on one or more certificate. A CertsQuery contains a list of certificates, and can also contain zero or one of each of the following items: ValidityTime, IntermediateCerts, TrustedRoots, RevocationInfo, UsageID, ConfigurationIdentifier, and Extensions. The list of certificates in the Query item tells the server the certificate(s) the client wants a reply for. The optional ValidityTime item tells the time at which the client wants to know about. The optional IntermediateCerts, TrustedRoots, RevocationInfo, UsageID, and ConfigurationIdentifier items tell the server how to process the request. The Extension item in the Query item applies only to the certificates in the list of certificates. If there is more than one certificate in the list, the other items all apply to every certificate in the list. 3.5 CertBundle The CertBundle item contains one or more certificates, represented as FullCert items and/or CertHash items. The order of the certificate(s) in the bundle is not important. The items that use CertBundle items specify the types of certificates that can be in the CertBundle items. 3.6 FullCert The FullCert item contains a complete certificate. The FullCert item contains an identifier for the type of certificate and the octets of the certificate itself. One type of certificate, for PKIX [PKIX], is defined, but other types of certificates (such as for OpenPGP [OpenPGP]) may be defined in the future. 3.7 CertHash The CertHash item contains the hash of a certificate. The CertHash item has an identifier for the type of certificate and the SHA-1 [SHA-1] hash of the octets of the certificate itself. One type of certificate, for PKIX, is defined, but other types of certificates (such as for OpenPGP) may be defined in the future. The client SHOULD only include CertHash items for certificates that the client knows the server is aware of. It makes no sense to send the hash of a certificate unless the server already has a complete copy of the certificate. 3.8 Extensions The Extensions item specifies a list of extensions to the SCVP protocol, for example to request additional information about the certificate(s) in the CertsQuery. The Extensions item contains a sequence of Extension items, each of which contain an ExtensionID item, an ExtensionCritical item, and an ExtensionValue item. 3.9 ExtensionID The ExtensionID item is an identifier for the extension. It contains the OID of the extension. 3.10 ExtensionCritical The ExtensionCritical item tells whether the extension is critical. The values for the item are: False Not critical True Critical In a request, if the ExtensionCritical item is true, the server MUST NOT process the request unless it understands the extension. In a reply, if the ExtensionCritical item is true, the client MUST NOT process the reply if unless it understands the extension. 3.11 ExtensionValue The ExtensionParameters item gives parameters for an extension. It contains a sequence of octets. 3.12 IntermediateCerts The IntermediateCerts item specifies to the server the intermediate certificates that the server MAY use when forming a certificate chain. The certificates in the IntermediateCerts item can be used by the server in addition to any other certificates that the server knows of when building chains. The IntermediateCerts item contains a list of certificates. The certificates in the IntermediateCerts MUST NOT be self-signed certificates. The purpose of the IntermediateCerts item is to help the server create validation chains. For example, the server may not have access to all intermediate certificates for an end-entity certificate, but the client has what it thinks are candidates for intermediate certificates because the end entity gave them to the client. Another example is that the client may have more up-to-date information than the server about certificates that have been rolled-over. 3.13 TrustedRoots The TrustedRoots item specifies to the server the root certificates that the server MUST use. If a TrustedRoots item is included in a CertsQuery item, the server MUST NOT use any roots other than the certificates in the TrustedRoots item when forming a certificate chain for validation. The TrustedRoots item contains a CertBundle item. The purpose of the TrustedRoots item is to tell the server which roots the client trusts. Many end-entity certificates have one or more intermediate certificates in the chain to a the root. If the client is not aware of the intermediate certificates, the TrustedRoots item tells the server only validate the chain that the server builds if the chain ends at one of the root certificates given. The TrustedRoots item can also tell a server which roots a client trusts in the case where the certificate in question might make different chains to different roots due to cross-certification. 3.14 RevocationInfo The RevocationInfo item specifies to the server revocation information such as CRLs and OCSP [OCSP] responses that the server MAY use when validating certificate chains. The purpose of the RevocationInfo item is to provide revocation information to the server that the server may not have access to, such as an OCSP response that the client received on its own OCSP request. Note that the information in the RevocationInfo item might not be used by the server, such as if the information is for certificates that the server does not use in chain building. Each type of revocation proof that can be requested is indicated by an OID from a standard arc. {revinfo-arc 1} CRL {revinfo-arc 2} OCSP response [[[Need to specify the format of the extensions for both CRLs and for OCSP responses.]]] 3.15 UsageID The UsageID item specifies to the server the policy ID that the server MUST use when forming a certificate chain. The UsageID item contains the OID of the policy. 3.16 ConfigurationIdentifier The ConfigurationIdentifier item tells the server the SCVP options that the client wants the server to use. The client can use this option instead of specifying other SCVP configuration such as UsageID, TrustedRoots, RevocationInfo, and so on. The value of this item is determined by private agreement between the client and the server and is not specified in this document. For example, the value might be the hash of some set of options, or it might be a short identifier for a common set of options. Further, the server might want to have identifiers that indicate that some settings are used in addition to others given in the request; in this way, the configuration identifier might be a shorthand for some SCVP options. 3.17 TypesOfCheck The TypesOfCheck item describes the kind of checking that the client wants the server to do on the certificate(s) in the Query item. If the TypesOfCheck item is given in a request, it can contain one or more types of checks. For each type of check specified in the request, the server MUST return information on what it found during the check. Each type of checks is indicated by an OID from a standard arc. {type-arc 0} Path validation to a trusted root {type-arc 1} Revocation status 3.18 WantBack The WantBack item describes the kind of information the client wants from the server for the certificate(s) in the Query item. If the WantBack item is given in a request, it can contain one or more types of information. For each type of information specified in the request, the server MUST return information on what it found during the check. Each type of information that can be requested is indicated by an OID from a standard arc. {want-arc 1} Certificate chain used to validate the certificate {want-arc 2} Proof of revocation status For example, a request might include a TypesOfCheck item that does not specify path validation, and include a WantBack item that specifies the certificate chain used to validate. The response would not include a status for the validation, but would include a certificate chain that the server thinks might validate. This set of options might be used by a client that wants to do its own path validation. 3.19 ValidityTime The ValidityTime indicates the time for which the client wants the information to be relevant. For example, when asking for validation of a certificate, the client might ask "was this certificate valid at this time". The information in the CertReply item in the response MUST be formatted as if the server created the response at the time indicated in the ValidityTime, except that if the server doesn't have historical information about that time, the information will be for a time later than the ValidityTime. A client MUST be able to handle responses that have ThisUpdate and NextUpdate items that are later than the requested ValidityTime. 3.20 RequestNonce The RequestNonce item is an identifier generated by the client for the request; the server MUST return the same RequestNonce in the signed part of the server's response. The RequestNonce item is simply a sequence of octets. The client SHOULD include a RequestNonce item in every request to prevent an attacker acting as a man-in-the-middle from replaying old responses from the server. The value of the nonce SHOULD change with every request sent from the client. 3.21 RequestHash The RequestHash item is the SHA-1 hash of the TBSRequest item. The RequestHash item serves the following purposes: - It helps a client know that the request was not maliciously modified when the client gets the response back - It allows the client to associate a response with a request when using connectionless protocols The purpose of the RequestHash is not for authentication of the client. The server MUST check the hash to verify that the request was not modified in transit, and MUST return the RequestHash item in the response. 3.22 RequestSignature The RequestSignature item is the signature of the TBSRequest item. The RequestSignature item contains a SignatureName item that is the name of the client, a SignatureAlgorithm item that is the algorithm used to sign the request, and a SignatureBits item that is the signature itself. The RequestSignature item may contain an optional KeyID item that identifies the signing key. The RequestSignature item may also contain an optional CertBundle that represents a chain of certs for the key used to sign the request. A RequestSignature item can be used to authenticate the client to the server and for non-repudiation of the client's request, such as for accounting purposes. A server might require all requests to be signed if the server did not want to respond to request unless they were from authenticated clients. A client does not need to sign a request in order to be sure that the response from a server is to the request that the client issued; the RequestHash is sufficient as long as the server checks the value of the RequestHash and signs its response to the client. 3.23 SignatureName The SignatureName item holds the name of a signer. It is used to associate a key with the request. 3.24 SignatureAlgorithm The SignatureAlgorithm identifies the algorithm used to sign a request or response. The SigningAlgorithm item contains the OID of the algorithm and any necessary parameters for the algorithm. 3.25 SignatureBits The SignatureBits item holds the octets of a signature. The structure of the SignatureBits item is determined by the value of the SignatureAlgorithm item. 3.26 KeyID The KeyID item contains the hash of a public key. The purpose of the KeyID is to identify the specific public key used by the named signer in the case that the signer has many public keys. The KeyID item has the SHA-1 hash of the octets of the key itself. [[[What bits are to be hashed?]]] 4. Responses A SCVP server's response to the client MUST be a single FullResponse item. The FullResponse item contains the entire response. A FullResponse item is carried in an application/scvp-response MIME body part. 4.1 FullResponse The FullResponse item encapsulates the server's response. The FullResponse item contains a TBSResponse item and a ResponseSignature item. 4.2 TBSResponse The TBSResponse item contains the part of the server's response that is signed by the ResponseSignature item. The item contains a Version item, a ProducedAt item, a ResponseStatus item, and a RequestHash item. The item can also contain an optional ReplyObjects item, an optional RequestNonce item, and an optional Extensions item. The TBSResponse item MUST contain exactly one CertReply item for each certificate requested in the request. The RequestNonce item MUST be included if the request had a RequestNonce item. 4.3 ProducedAt The ProducedAt item tells the time at which the whole response was produced. The ProducedAt item represents the date at Greenwich Mean Time. 4.4 ResponseStatus The ResponseStatus item gives status information to the client about its request. The ResponseStatus item has a numeric status code and an optional string that is a sequence of characters from the ISO/IEC 10646-1 character set encoded with the UTF-8 transformation format defined in [UTF8]. The optional string may be used to transmit status information, but it is optional. The client MAY choose to display the string to the client. However, because there is no way to know the languages understood by the user, the string may be of little or no use to them. The complete list of status codes for the ResponseStatus item is: 0 The request was fully processable 1 The request included unrecognized items; continuing 10 Too busy; try again whenever you feel like it 11 Too busy; try again later than 10 seconds from now 12 Too busy; try again later than 60 seconds from now 20 The structure of the request was wrong 21 The version of request is not supported by this server 22 The request included unrecognized items; aborting 23 The key given in the RequestSignature is not recognized 24 The signature did not match the body of the request 25 The hash in the RequestHash did not compute 26 The request was not authorized 4.5 ReplyObjects The ReplyObjects item returns objects to the client. In this specification, the ReplyObjects item is always a CertReply, which tells the client about a single certificate from the request. The CertReply item contains a CertHash item identifying the certificate, a ReplyStatus item, a ThisUpdate item, and a NextUpdate item. There may also be the following optional items: ValidationStatus, RevocationStatus, PublicKey, CertSubject, ValidationChain, RevocationProof, and Extensions. The presence or absence of the ValidationStatus, RevocationStatus, PublicKey, CertSubject, ValidationChain, and RevocationProof items in the CertReply item is controlled by the TypesOfCheck, and WantBack items in the request. A server MUST include one of the above items for each related item requested in the TypesOfCheck, and WantBack items. An Extensions item in the response MAY be in response to an Extensions item in the request, but the server MAY include an Extensions item in a response even if the request did not have an Extensions item. 4.6 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 certificate. The complete list of status codes for the ReplyStatus item is: 0 Success: a definitive answer follows 1 Failure: the certificate type is not recognized 2 Failure: an item wanted in TypesOfCheck is not recognized 3 Failure: an item wanted in WantBack is not recognized 4 Failure: the certificate was malformed 5 Failure: the mandatory UsageID is not recognized 6 Failure: the ConfigurationIdentifier is not recognized 7 Failure: unauthorized request Status code 4 is used to tell the client that the request was properly formed but the certificate in question was not. This is useful to clients that cannot parse a certificate. 4.7 ThisUpdate The ThisUpdate item tells the time at which the information in the CertReply was correct. The ThisUpdate item represents the date at Greenwich Mean Time. 4.8 NextUpdate The NextUpdate item tells the time until which the server expects the information in the CertReply to be valid. The NextUpdate item represents the date at Greenwich Mean Time. [[[Is there a desire for another item that says "the server takes liability for this response up to this particular time?]]] 4.9 ReplyTypesOfCheck The ReplyTypesOfCheck contains the responses to the client's TypesOfCheck item in the request. It has the same form as the Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match the OIDS in the TypesOfCheck item. The value for path validation to a trusted root, {type-arc 0}, can be one of the following: 0 Valid 1 Not valid 2 Temporarily unknown 3 Unknown The value for the revocation status, {type-arc 1}, can be one of the following: 0 Good 1 Revoked 2 Temporarily unknown 3 Unknown 4.10 ReplyWantBack The ReplyWantBack contains the responses to the client's WantBack item in the request. It has the same form as the Extensions item, and the OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack item. The value for the certificate chain used to validate the certificate in the request, {want-arc 1}, is a CertBundle item. The value for the proof of revocation status, {want-arc 2}, is a RevocationProof item. 4.11 RevocationProof The RevocationProof item gives the client the proof that the server used to check revocation. The structure of the RevocationProof item is the same as an Extensions item. The OIDs in the RevocationProof item are the same as those in the RevocationInfo item. 4.12 ResponseSignature The ResponseSignature item is the signature of the TBSResponse item. The ResponseSignature item contains a Name item that is the name of the server, a SigningAlgorithm item that is the algorithm used to sign the response, and a SignatureBits item that is the signature itself. The ResponseSignature item may contain an optional KeyID item that identifies the signing key. The ResponseSignature item may also contain an optional CertBundle that represents a chain of certs for the key used to sign the response. The client SHOULD check the signature on every message it receives from the server, and MUST check the signature on every message that includes validation and/or revocation information on which the client will rely. In order to check the signature, the client MUST know and rely on the public signing key of the server. The client could have obtained the server's public key through an out-of-band mechanism of direct trust or through a certificate that chains to a root that the client trusts to delegate this type of authority. 5. ASN.1 Syntax for SCVP This section defines the syntax for SCVP messages. The semantics for the messages are defined in sections 2, 3, and 4. Note that the ASN.1 syntax here is purposely designed to ease the job of "hand-coding" the messages while still making the syntax easy for ASN.1 compilers to work with. It is also designed so that it is easy for developers of other PKI protocols to reuse the syntax with minimal changes. SCVP DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS ; -- TO BE DONE. Will include Certificate, Name, -- AlgorithmIdentifier, and GeneralizedTime. FullRequest ::= SEQUENCE { tbsRequest TBSRequest, requestHash OCTET STRING, requestSignature Signature OPTIONAL } TBSRequest ::= SEQUENCE { version INTEGER, query Query, typesOfCheck TypesOfCheck, wantBack WantBack, requestNonce [0] OCTET STRING OPTIONAL, extensions [1] Extensions OPTIONAL } Query ::= CHOICE { certsQuery [0] CertsQuery } CertsQuery ::= SEQUENCE { queriedCerts SEQUENCE OF Cert, validityTime [0] GeneralizedTime OPTIONAL, intermediateCerts [1] SEQUENCE OF Cert OPTIONAL, trustedRoots [2] CertBundle OPTIONAL, revocationInfos [3] Extensions OPTIONAL, usageID [4] OBJECT IDENTIFIER OPTIONAL, configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, extensions [6] Extensions OPTIONAL } CertBundle ::= SEQUENCE OF CertItem CertItem ::= CHOICE { fullCert [0] Cert, certHash [1] CertHash } Cert ::= CHOICE { pkixCert [0] Certificate } CertHash ::= CHOICE { pkixCertHash [0] OCTET STRING } TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { ExtensionID OBJECT IDENTIFIER, ExtensionCritical BOOLEAN DEFAULT FALSE, ExtensionValue OCTET STRING } Signature ::= SEQUENCE { signerName Name, signatureAlgorithm AlgorithmIdentifier, signatureBits BIT STRING, keyID [0] OCTET STRING OPTIONAL, certs [1] CertBundle OPTIONAL } FullResponse ::= SEQUENCE { tbsResponse TBSResponse, responseSignature Signature } TBSResponse ::= SEQUENCE { version INTEGER, producedAt GeneralizedTime, responseStatus ResponseStatus, requestHash OCTET STRING, replyObjects [0] ReplyObjects OPTIONAL, requestNonce [1] RequestNonce OPTIONAL, extensions [2] Extensions OPTIONAL } ResponseStatus ::= SEQUENCE { statusCode INTEGER, errorMessage [0] UTF8String OPTIONAL } ReplyObjects ::= CHOICE { certReplies [0] SEQUENCE OF CertReply } CertReply ::= SEQUENCE { certHash OCTET STRING, replyStatus ReplyStatus, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, replyTypesOfCheck [0] Extensions OPTIONAL, replyWantBack [1] Extensions OPTIONAL, extensions [2] Extensions OPTIONAL } ReplyStatus ::= ENUMERATED { success (0), certTypeUnrecognized (1), typeOfCheckUnrecognized (2), wantBackUnrecognized (3), certMalformed (4), usageIDUnrecognized (5), configInfoUnrecognized (6), unauthorizedRequest (7) } -- Need to include type-arc, want-arc, and revinfo-arc END 6. Security Considerations A client that trusts a server's responses for validation of certificates 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 weakest root server that the SCVP server trusts. If a server does not check the RequestHash or the signature in the optional RequestSignature item and the request contains certificates that are not being validated, a man-in-the-middle attack could change the values of the certificates and cause the server to give different answers to a request. 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. This attack does not affect the usefulness of some responses (such as a response that returns a certificate path that the client will validate itself) but does affect things such as a validation response. If the client does not include a RequestNonce item, or if the client does not check that the RequestNonce in the reply matches that in the request, an attacker can replay previous responses from the server. This attack can also be mounted, even with signed requests, if the server does not keep track of previous RequestNonce items. If the server does not require some sort of authorization (such as signed requests), an attacker can get the server to reply to arbitrary requests. Such responses may give the attacker information about weaknesses in the server or about the timeliness of the server's checking. This information may be valuable for a future attack. A. References [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560. [OpenPGP] "OpenPGP Message Format", RFC 2440. [PKIX] "PKIX Certificate and CRL Profile", RFC 2459. [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April 1995. [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. B. Acknowledgments The lively debate in the PKIX Working Group also had a significant impact on the types of items described in this protocol. Denis Pinkas suggested some additional requirements for the protocol, and Mike Myers helped point out sections that needed clarification. C. Changes Between Versions of This Document C.1 Differences between -00 and -01 1: Rewrote to both narrow focus and to explain the goals more fully. 1.1: Removed second paragraph. 2: Removed the discussion of the two syntaxes. 3: Reorganized the section to put the Extensions items after the CertsQuery items. The section numbers below are from the -00 draft. Throughout the section, made RequestHash mandatory instead of optional. Added RevocationInfo item. Changed CertID to CertHash throughout. Fixed the names of the parts of the signature to match the text. 3.1: Split the item into a TBSRequest followed by the hash and/or signature. Changed the order of the extensions item so that all the optional items were together. Changed CertsQuery into Query. Added the ValidityTime item. 3.3: Redefined Extension to be Extensions to be more similar to Extensions in PKIX. Other wording changes. 3.5: Gave more explanation for the ExtensionCritical bit, and made the values boolean. Note that this item may disappear, depending on discussion of the open issue on it. 3.7: Changed CertsQuery into Query and described the one defined instance as CertsQuery. Moved the TypesOfCheck and WantBack from the Query and up one level to the TBSRequest. 3.9: Removed OpenPGP cert, but allowed for it to be added back in the future. 3.10: Removed OpenPGP cert hash, but allowed for it to be added back in the future. 3.11 Made TypesOfCheck OIDs. 3.12: Made WantBack OIDs. Removed the public key and the names. 3.10: Added sentence about when a client might include a CertHash item in the TrustedRoots. 3.13: Clarified use of IntermediateCerts 3.18: Added wording that the RequestHash should not be used for authentication. 3.19: Changed wording to make it clear that RequestSignature was needed only for authentication of the client. 3.23: Clarified purpose of KeyID. 4: The section numbers below are from the -00 draft. Throughout the section, made returning the RequestHash mandatory because it is now mandatory in the request. 4.1: Split the item into a TBSResponse followed by the hash and/or signature. Made ResponseSignature mandatory. Made the items returned in the form of Extensions to match the fact that TypesOfCheck and WantBack are now sequences of OIDs. 4.3: Made the status code a single number. 4.4 Removed the subject names and public keys. Added NextUpdate. 4.10: Clarified that CertSubject for PKIX certs must contain both the subject name and the subjectAltName. 4.13: Made ResponseSignature mandatory; this might be changed back to optional for some types of responses in a future revision of the spec. Added a discussion of how the client can get the server's signing key. Old 5: Removed tiny syntax, renumbered old 6 to 5. 5: Added note about semantics in 2-4. Split FullRequest into FullRequest and TBSRequest. Moved the extensions item in FullRequest. Changed the certsQuery to Query. Move TypesOfCheck and WantBack up to TBSRequest. Made TypesOfCheck and WantBack SEQUENCE of OIDs. Added ValidityTime. Changed "CertID" to "CertHash". Made the status code a single number. Added reminder in CertItem about full certs. Changed order of Signature items. Split FullResponse into FullResponse and TBSResponse. Added ReplyTypesOfChecks and ReplyWantBack items. Added Extensions item and sub-items. 7: Updated to reflect mandatory RequestHash and ResponseSignature. Added explicit words about compromise of the SCVP server. Removed the first paragraph because it was confusing and will be fixed in later versions of the draft. A: Added reference to OCSP. D: Updated. D. MIME Registrations D.1 Registration for application/scvp-request [TBD] D.2 Registration for application/scvp-response [TBD] E. Author Contact Information Ambarish Malpani ValiCert 1215 Terra Bella Ave. Mountain View, CA 94043-1833 ambarish@valicert.com Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA paul.hoffman@vpnc.org