Internet Draft Ambarish Malpani draft-ietf-pkix-scvp-00.txt ValiCert June 25, 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 RFC2026. 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 it is valid, what the public key and subject of the certificate is, and so on. 1. Introduction Certificate validation is a difficult problem to solve. If certificate handling is to be widely deployed in applications, the amount of processing an application needs to perform before it can accept a certificate must be greatly reduced. There are a variety of applications that can use public key certificates but are burdened by the overhead of parsing and validating the certificates when all the application really wants is the public key from the certificate and a determination of whether or not the certificate may be used for a particular purpose. The goals of SCVP are: - Make it easier for applications to deploy PKI based systems - Enable the PKI to be used on low-end devices such as telephones - Allow centralization of administering PKI policies 1.1 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. In sections 3 and 4, values are given in decimal notation. In section 5, values are given in hexadecimal notation. Hexadecimal values are indicated as "xNN" or "xNNNN". For example, xA0B1 corresponds to the octet xA0 followed by the octet xB1. 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 SVCP is expected to be over HTTP, and possibly email. This document registers MIME types for SVCP requests and responses. There are two syntaxes for SCVP: a "tiny" syntax designed for clients that do not have ASN.1 parsers, and an ASN.1 syntax for clients that prefer ASN.1 formats. The semantics are identical for each format; the only difference is the bits on the wire for the requests and replies. The semantics are described in sections 3 (requests) and 4 (responses). The syntaxes are described in sections 5 (tiny syntax) and 6 (ASN.1). The primary reason for the SCVP protocol to have two different syntaxes is that SCVP is aimed at two different markets that have different code bases. Manufacturers of mall devices such as cell phones may not want to incur the large overhead of an ASN.1 encoder/decoder in their devices and might thus not use SCVP. On the other hand, developers of programs that already have ASN.1 compilers built into them may not want to add the overhead of a second syntax if they can just use ASN.1. It is expected that individual SCVP clients will only use one of the two syntaxes, but that most or all SCVP servers will be able to handle both. Because of the nature of the checking that they are doing, SCVP servers must be able to process ASN.1; the additional overhead of parsing queries and forming responses using the tiny syntax should be relatively small. 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 Version item, zero or more Extension items, a CertsQuery items, an optional RequestNonce item, an optional RequestHash item, and an optional RequestSignature item. 3.2 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.3 Extension The Extension item specifies an extension to the SCVP protocol, for example to request additional information about the certificate(s) in the CertsQuery. The Extension contains an ExtensionID item, an ExtensionCritical item, and an ExtensionValue item. 3.4 ExtensionID The ExtensionID item is an identifier for the extension. It contains the OID of the extension. 3.5 ExtensionCritical The ExtensionCritical item tells whether the extension is critical. The values for the item are: 0 Not critical 1 Critical 3.6 ExtensionValue The ExtensionParameters item gives parameters for an extension. It contains a sequence of octets. 3.7 CertsQuery The CertsQuery item specifies a request for information on one or more certificate. A CertsQuery contains a CertBundle item, a TypesOfCheck item, and a WantBack item. A CertsQuery item can also contain zero or more Extension items, and zero or one of each of the following items: IntermediateCerts, TrustedRoots, UsageID, and ConfigurationIdentifier. The CertBundle item tells the server the certificate(s) the client wants a reply for; the certificate(s) in the CertBundle item in the CertsQuery item MUST be FullCert items. The TypesOfCheck item tells the server what types of checking it should do on the certificate(s), and the WantBack item tells the server what the client wants to know about the certificate(s). The optional IntermediateCerts, TrustedRoots, UsageID, and ConfigurationIdentifier items tell the server how to process the request. If there is more than one certificate in the CertBundle item, the other items all apply to every certificate in the CertBundle item. 3.8 CertBundle The CertBundle item contains one or more certificates, represented as FullCert items and/or CertID 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.9 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. The types of certificates are: 0 PKIX [PKIX] 1 OpenPGP [OpenPGP] 3.10 CertID The CertID item contains the hash of a certificate. The CertID item has an identifier for the type of certificate and the SHA-1 [SHA-1] hash of the octets of the certificate itself. The types of certificates are: 0 PKIX [PKIX] 1 OpenPGP [OpenPGP] 3.11 TypesOfCheck The TypesOfCheck item describes the kind of checking that the client wants the server to do on the certificate(s) in the CertsQuery 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. The types of checks are: 0 Path validation to a trusted root 1 Revocation status 3.12 WantBack The WantBack item describes the kind of information the client wants from the server for the certificate(s) in the CertsQuery 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. The types of information that can be requested are: 0 Public key of the subject of the certificate 1 Subject of the certificate 2 Certificate chain used to validate the certificate 3 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.13 IntermediateCerts The IntermediateCerts item specifies to the server the intermediate certificates that the server MAY use when forming a certificate chain in addition to any other certificates that the server knows of. The IntermediateCerts item contains a CertBundle item; the certificate(s) in the CertBundle item MUST be FullCert items. The certificates in the IntermediateCerts MUST NOT be self-signed certificates. 3.14 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 certificate(s) in the TrustedRoots MAY be FullCert items or CertID items. 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, 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 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.18 RequestHash The RequestHash item is the SHA-1 hash of all the items in the FullRequest other than the RequestHash item and the RequestSignature items. The RequestHash item serves many purposes: - It helps the server check if there was accidental modification of a request in transit if the request was not signed - It helps a client using unsigned requests 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 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.19 RequestSignature The RequestSignature item is the signature of all the items in the FullRequest item other than the RequestSignature item itself. The RequestSignature item contains a Name item that is the name of the client, a SigningAlgorithm item that is the algorithm used to sign the request, and a SignatureBits item that is the signature itself. The RequestSignature item may contain a 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. Requests SHOULD include a RequestSignature item. The only situation in which a request need not be signed is when the request is done over an authenticated channel, such as through a connection secured with IPsec or through signed email messages. 3.20 Name The Name item holds the name of a signer. It is used to associate a key with the request. 3.21 SigningAlgorithm The SigningAlgorithm 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.22 SignatureBits The SignatureBits item holds the octets of a signature. The structure of the SignatureBits item is determined by the value of the SigningAlgorithm item. 3.23 KeyID The KeyID item contains the hash of a public key. 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 item contains a Version item, a ProducedAt item, a ResponseStatus item, optional Extension items, optional CertReply items, an optional RequestNonce item, an optional RequestHash item, and an optional ResponseSignature item. The FullResponse 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. The RequestHash item MUST be included if the request had a RequestHash item. 4.2 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.3 ResponseStatus The ResponseStatus item gives status information to the client about its request. The ResponseStatus item has a main status code, a secondary 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 values for the main status code are based loosely on those in SMTP. They are: 0 - positive completion 1 - transient negative completion 2 - permanent negative completion After validating the signature on a response, a client MAY use just the main status code to decide how to display any results of the request to the user who made the request. The complete list of status codes for the ResponseStatus item (displayed as main code, secondary code, and meaning) is: 0 0 The request was fully processable 0 1 The request included unrecognized items; continuing 1 0 Too busy; try again whenever you feel like it 1 1 Too busy; try again later than 10 seconds from now 1 2 Too busy; try again later than 60 seconds from now 2 0 The structure of the request was wrong 2 1 The version of request is not supported by this server 2 2 The request included unrecognized items; aborting 2 3 The key given in the RequestSignature is not recognized 2 4 The signature did not match the body of the request 2 5 The hash in the RequestHash did not compute 2 6 The request was not authorized 4.4 CertReply The CertReply item tells the client about a single certificate from the request. The CertReply item contains a CertID item identifying the certificate, a ReplyStatus item, and a ThisUpdate item. There may be zero or more Extension items. There may also be the following optional items: ValidationStatus, RevocationStatus, PublicKey, CertSubject, ValidationChain, and RevocationProof. 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. 4.5 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.6 ThisUpdate The ThisUpdate item tells the time at which the information in the CertReply was produced. The ThisUpdate item represents the date at Greenwich Mean Time. 4.7 ValidationStatus The ValidationStatus item tells the client whether or not the certificate is valid based on chaining to a trusted root key. The values for ValidationStatus are: 0 Valid 1 Not valid 2 Temporarily unknown 3 Unknown 4.8 RevocationStatus The RevocationStatus item tells the client whether or not the certificate has been revoked. The values for RevocationStatus are: 0 Good 1 Revoked 2 Temporarily unknown 3 Unknown [[[Should we add a field to specify the reasons for revocation?]]] 4.9 PublicKey The PublicKey item tells the client the public key in the certificate. [[[More is needed here about the format for the reply. Is it just the bits from the certificate, or is there some structure with the type of key returned? What about OpenPGP keys?]]] 4.10 CertSubject The CertSubject item tells the client the subject of the certificate. [[[Much more is needed here about the format for the reply. Is it a sequence of bits, or does it have structure? What about subjectAltName? What about OpenPGP subjects?]]] 4.11 ValidationChain The ValidationChain item tells the client the chain of certificates that was used to validate the certificate. The ValidationChain item contains a CertBundle item. The certificate(s) in the CertBundle item MAY be either FullCert items or CertID items. 4.12 RevocationProof The RevocationProof item gives the client the proof that the server used to check revocation. This can be either the full OCSP response that the server used, or the CRL(s) used to determine the revocation information. [[[More is needed here, such as a structure to say what kind of item is included.]]] 4.13 ResponseSignature The ResponseSignature item is the signature of all the items in the FullResponse item other than the ResponseSignature item itself. 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 a 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. Responses SHOULD include a ResponseSignature item. A server might not sign a reponse if the response only contains an error code in the ResponseStatus. Another situation in which a response need not be signed is when the response is done over an authenticated channel, such as through a connection secured with IPsec or through signed email messages. 5. Tiny Syntax for SCVP Tiny syntax SCVP requests and responses have a simple format. The format is optimized for simple processing in small clients. An explicit design goal of the tiny syntax SCVP is to greatly reduce code overhead by not requiring clients to have to use a generalized ASN.1 processor for creating requests and understanding responses. The basic unit of the tiny syntax is the item. A tiny syntax item consists of exactly three parts: - a two-octet tag - a four-octet length - content whose length and structure are defined by the tag Each of the three parts of an are in network byte order, as is the entire item. The tag values are given in this section. The length is the number of octets in the content of the item. Some tags define fixed-length content, while other tags define variable-length content. The structure of the content of each item is defined in the item; there is no data typing in the tiny syntax. A program parsing a request or response can easily skip over items whose tags it doesn't recognize by reading the tag, reading the length, and skipping over the number of octets given in the length to get to the beginning of the next item. Because of this, no data typing is needed. 5.1 Tiny syntax of items The following table lists the items from sections 3 and 4, and gives the tag values and structure of each. Item Tag Structure FullRequest x0000 A Version item, followed by zero or more Extension items, followed by a CertsQuery items, followed by zero or one RequestNonce item, followed by zero or one RequestHash item, followed by zero or one RequestSignature item. Version x0001 One octet. Extension x001C An ExtesnionID item, followed by an ExtensionCritical item, followed by an ExtensionParameters item. ExtensionID x001D A sequence of octets. ExtensionCritical x001E One octet. ExtensionParameters x001F A sequence of octets. CertsQuery x0002 A CertBundle item, followed by a TypesOfCheck item, followed by a WantBack item, followed by zero or more Extension items, followed by an unordered set of zero or one of each of the following items: IntermediateCerts, TrustedRoots, UsageID, and ConfigurationIdentifier. CertBundle x0003 An unordered set of one or more of certificates. FullCert x0004 A single octet representing the type of certificate, followed by the octets that make up the certificate. CertID x0005 A single octet representing the type of certificate, followed by the 20 octets that make up the hash of the certificate. TypesOfCheck x0006 One octet for each type of check. WantBack x0007 One octet for each item wanted back. IntermediateCerts x0008 A CertBundle item. TrustedRoots x0009 A CertBundle item. UsageID x000A A sequence of octets. ConfigurationIdentifier x000B A sequence of octets. RequestNonce x000C A sequence of octets. RequestHash x000D The 20 octets that make up the hash. RequestSignature x000E A Name item, followed by a SigningAlgorithm item, followed by a SignatureBits item, followed by zero or one KeyID item, followed by zero or one CertBundle item. Name x0020 A sequence of octets. SigningAlgorithm x0021 A sequence of octets. SignatureBits x0022 A sequence of octets. KeyID x0023 The 20 octets that make up the hash. FullResponse x0010 A Version item, followed by a ProducedAt item, followed by a ResponseStatus items, followed by zero or more Extension items, followed by zero or more CertReply items, followed by zero or one RequestNonce items, followed by zero or one ResponseSignature items. ProducedAt x0024 14 octets representing the date in YYYYMMDDHHMMSS format. ResponseStatus x0011 One octet for the main status code, followed by one octet for the secondary status code, followed by zero or more octets that make up the string of characters. CertReply x0012 One CertID item, followed by a ReplyStatus item, followed by a ThisUpdate item, followed by zero or more Extension items, followed by zero or one of each of the following items: ValidationStatus, RevocationStatus, PublicKey, CertSubject, ValidationChain, and RevocationProof. ReplyStatus x0013 A single octet. ThisUpdate x0014 14 octets representing the date in YYYYMMDDHHMMSS format. ValidationStatus x0015 A single octet. RevocationStatus x0016 A single octet. PublicKey x0017 A sequence of octets. CertSubject x0018 A sequence of octets. ValidationChain x0019 A CertBundle item. RevocationProof x001A A sequence of octets. ResponseSignature x001B A Name item, followed by a SigningAlgorithm item, followed by a SignatureBits item, followed by zero or one KeyID item, followed by zero or one CertBundle item. 5.2 Examples of tiny syntax The following is an example of a simple request. The client is asking the server for validation and revocation information on a single certificate, as well as for the public key and the subject name that is contained in the certificate. The structure for this request can be viewed as: FullRequest ( Version ( x01 ) CertsQuery ( CertBundle ( FullCert ( x00 ) ) TypesOfCheck ( x00 x01 ) WantBack ( x00 x01 ) ) ) RequestNonce ( ) RequestHash ( ) RequestSignature ( Name ( ) SigningAlgorithm ( ) SignatureBits ( ) ) ) The actual request would be as follows (note that some of the values here are made up): 0000 0000 0157 FullRequest tag, length 0001 0000 0001 Version tag, length 01 Version number 0002 0000 00BF CertsQuery tag, length 0003 0000 00A9 CertBundle tag, length 0004 0000 00A3 FullCert tag, length 00 PKIX cert 66A2 920B FF24 8A90 017D 3282 421A B230 Contents of cert 0000 008B 4308 A3B8 FFC7 0530 0306 0800 ... . . . 0006 0000 0002 TypesOfCheck tag, length 00 Want path validation 01 Want revocation status 0007 0000 0002 WantBack tag, length 00 Want public key 01 Want subject 000C 0000 0008 RequestNonce tag, length 8BFA 8D50 FF80 3819 The nonce 000D 0000 0014 RequestHash tag, length C074 FEFF 0950 E885 A1C0 1006 0885 FF83 The hash 1B42 ... 000E 0000 005D RequestSignature tag, len. 0020 0000 0004 Name tag, len. 4269 6C6C The name 0021 0000 0007 SigningAlgorithm tag, len. 2A86 48CE 3804 01 The OID 0022 0000 0040 SignatureBits, len. A1C0 1006 0885 C074 0950 E885 FEFF FF83 Contents of the signature C404 6880 AC05 08E8 78FE FFFF E807 FAFF . . . The following is an example of the reply to the preceding simple request. The server says that the cert is valid, not revoked, and gives the subject name and the public key from the certificate. The structure for this response can be viewed as: FullResponse ( Version ( x01 ) ProducedAt ( ) ResponseStatus ( ) CertReply ( CertID ( ) ReplyStatus ( ) ThisUpdate ( ) RevocationStatus ( ) ValidationStatus ( ) CertSubject ( ) PublicKey ( ) ) RequestNonce( ) ResponseSignature( Name ( ) SigningAlgorithm ( ) SignatureBits ( ) ) ) The actual reply would be as follows (note that some of the values here are made up): 0010 0000 0319 FullResponse tag, length 0001 0000 0001 Version tag, length 01 00XX 0000 000E ProducedAt tag, length 3139 3939 3036 3133 3037 3532 3231 Date: 19990613075221 0011 0000 000C ResponseStatus, length 00 OK main status 00 OK secondary status 4E6F 2070 726F 626C 656D Some text 0012 0000 0270 CertReply tag, length 0005 0000 0015 CertID tag, length 00 PKIX cert A255 920B FF24 8A90 017D 3282 421A B230 Hash of cert 31ED EB00 ... 0013 0000 0001 ReplyStatus tag, length 00 OK status 0014 0000 000E ThisUpdate tag, length 3139 3939 3036 3133 3037 3532 3230 Date: 19990613075220 0016 0000 0001 RevocationStatus tag, len. 00 OK 0015 0000 0001 ValidationStatus tag, len. 00 OK 0018 0000 0020 CertSubject tag, length 83C3 0483 3B00 75F4 8B5D FCC9 C38D 7600 The subject 5589 E5C9 C390 9090 5589 E5FF 750C FF75 000C 0000 0008 RequestNonce tag, length 0017 0000 0200 PublicKey tag, length 50E8 AEFE FFFF 89F6 5589 E553 BB2C 0106 512-bit key 0883 3D2C 0106 0800 740E 89F6 8B03 FFD0 ... ... 8BFA 8D50 FF80 3819 The nonce 001B 0000 005C ResponseSignature, length 0020 0000 0003 Name tag, len. 4D6F 6D The name 0021 0000 0007 SigningAlgorithm tag, len. 2A86 48CE 3804 01 The OID 0022 0000 0040 SignatureBits, len. 40FC FFFF 6A01 6A02 E837 FCFF FFE8 6AE9 Contents of the signature 0000 31C0 C9C3 89F6 5589 E581 EC5C 3C01 ... . . . 6. ASN.1 Syntax for SCVP SCVP DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS ; -- TO BE DONE FullRequest ::= SEQUENCE { version Version, extensions [0] Extensions OPTIONAL, certsQuery CertsQuery, requestNonce [1] RequestNonce OPTIONAL, requestHash [2] RequestHash OPTIONAL, requestSignature [3] Signature OPTIONAL } Version ::= INTEGER RequestNonce ::= OCTET STRING RequestHash ::= OCTET STRING CertsQuery ::= SEQUENCE { certBundle CertBundle, typesOfCheck TypesOfCheck, wantBack WantBack, extensions [0] Extensions OPTIONAL, intermediateCerts [1] IntermediateCerts OPTIONAL, trustedRoots [2] TrustedRoots OPTIONAL, usageID [3] OBJECT IDENTIFIER OPTIONAL, configurationIdentifier [4] OBJECT IDENTIFIER OPTIONAL } CertBundle ::= SEQUENCE OF CertItem CertItem ::= CHOICE { fullCert [0] Cert, certID [1] CertID } Cert ::= CHOICE { pkixCert [0] Certificate, pgpCert [1] OCTET STRING } CertID ::= CHOICE { pkixCert [0] OCTET STRING, pgpCert [1] OCTET STRING } TypesOfCheck ::= BIT STRING { pathValidation (0), revocationStatus (1) } WantBack ::= BIT STRING { subjectPubKey (0), subjectName (1), certChain (2), revocationProof (3) } IntermediateCerts ::= CertBundle TrustedRoots ::= CertBundle Signature ::= SEQUENCE { signerName Name, keyID [0] KeyID OPTIONAL, signatureAlgorithm AlgorithmIdentifier, signatureBits BIT STRING, certs [1] CertBundle OPTIONAL } KeyID ::= OCTET STRING FullResponse ::= SEQUENCE { version Version, producedAt GeneralizedTime, responseStatus ResponseStatus, extensions [0] Extensions OPTIONAL, certReplies [1] SEQUENCE OF CertReply OPTIONAL, requestNonce [2] RequestNonce OPTIONAL, requestHash [3] RequestHash OPTIONAL, responseSignature [4] Signature OPTIONAL } ResponseStatus ::= SEQUENCE { mainStatus INTEGER, secondaryStatus INTEGER, errorMessage [0] UTF8String OPTIONAL } CertReply ::= SEQUENCE { certID CertID, replyStatus ReplyStatus, thisUpdate GeneralizedTime, singleExtensions [0] Extensions OPTIONAL, validationStatus [1] ValidationStatus OPTIONAL, revocationStatus [2] RevocationStatus OPTIONAL, subjectPublicKey [3] SubjectPublicKeyInfo OPTIONAL, -- OK for PGP? subjectName [4] Name OPTIONAL, -- OK for PGP? validationChain [5] SEQUENCE OF CertItem OPTIONAL, revocationProofs [6] SEQUENCE OF RevocationProof OPTIONAL } ReplyStatus ::= ENUMERATED { success (0), certTypeUnrecognized (1), typeOfCheckUnrecognized (2), wantBackUnrecognized (3), certMalformed (4), usageIDUnrecognized (5), configInfoUnrecognized (6), unauthorizedRequest (7) } ValidationStatus ::= ENUMERATED { valid (0), notValid (1), temporarilyUnknown (2), unknown (3) } RevocationStatus ::= ENUMERATED { good (0), revoked (1), temporarilyUnknown (2), unknown (3) } RevocationProof ::= SEQUENCE { type OBJECT IDENTIFIER, proof OCTET STRING -- DER encoding of proof defined by type } END 7. Security Considerations The current draft doesn't specify how the security algorithms will be used, and thus doesn't give enough detail to analyze the security considerations of the specification. If a request has neither a RequestHash item nor a 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. The same attack is available if the server does not check the hash or the signature on the request. If a response does not have a ResponseSignature item and is transmitted over an insecure channel, 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. The same attacks are available if the client does not check the signature on the 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. 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. [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 Graham Klyne provided suggestions to a different draft that are reflected in this one. C. Changes Between Versions of This Document None yet. 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