idnits 2.17.1
draft-ietf-pkix-scvp-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 1373 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack an Authors' Addresses Section.
** There are 3 instances of too long lines in the document, the longest one
being 9 characters in excess of 72.
** There is 1 instance of lines with control characters in the document.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 123: '...st to the server MUST be a single Full...'
RFC 2119 keyword, line 212: '...Critical item is true, the server MUST...'
RFC 2119 keyword, line 214: '...ical item is true, the client MUST NOT...'
RFC 2119 keyword, line 225: '... that the server MAY use when forming ...'
RFC 2119 keyword, line 229: '...s in the IntermediateCerts MUST NOT be...'
(47 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 53 has weird spacing: '...ier for appli...'
== Line 408 has weird spacing: '...est was not m...'
** The document contains RFC2119-like boilerplate, but doesn't seem to
mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but
that reference does not seem to mention RFC 2119 either.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'MUSTSHOULD' on line 958 looks like a
reference
-- Missing reference section? 'PKIX' on line 965 looks like a reference
-- Missing reference section? 'OpenPGP' on line 963 looks like a reference
-- Missing reference section? 'OCSP' on line 961 looks like a reference
-- Missing reference section? 'UTF8' on line 970 looks like a reference
-- Missing reference section? '0' on line 646 looks like a reference
-- Missing reference section? '1' on line 647 looks like a reference
-- Missing reference section? '2' on line 648 looks like a reference
-- Missing reference section? '3' on line 629 looks like a reference
-- Missing reference section? '4' on line 595 looks like a reference
-- Missing reference section? '5' on line 596 looks like a reference
-- Missing reference section? '6' on line 597 looks like a reference
-- Missing reference section? 'XMLDSIG' on line 972 looks like a reference
-- Missing reference section? 'XML-ns' on line 684 looks like a reference
-- Missing reference section? 'SHA-1' on line 967 looks like a reference
Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Ambarish Malpani
2 draft-ietf-pkix-scvp-03.txt ValiCert
3 June 12, 2000 Paul Hoffman
4 Expires in six months VPN Consortium
6 Simple Certificate Validation Protocol (SCVP)
8 Status of this memo
10 This document is an Internet-Draft and is in full conformance with all
11 provisions of Section 10 of RFC 2026.
13 Internet-Drafts are working documents of the Internet Engineering Task
14 Force (IETF), its areas, and its working groups. Note that other
15 groups may also distribute working documents as Internet-Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six months
18 and may be updated, replaced, or obsoleted by other documents at any
19 time. It is inappropriate to use Internet-Drafts as reference material
20 or to cite them other than as "work in progress."
22 The list of current Internet-Drafts can be accessed at
23 http://www.ietf.org/ietf/1id-abstracts.txt
25 The list of Internet-Draft Shadow Directories can be accessed at
26 http://www.ietf.org/shadow.html.
28 Abstract
30 The SCVP protocol allows a client to offload certificate handling to a
31 server. The server can give a variety of valuable information about the
32 certificate, such as whether or not the certificate is valid, a chain
33 to a trusted certificate, and so on. SCVP has many purposes, including
34 simplifying client implementations and allowing companies to centralize
35 their trust and policy managment.
37 1. Introduction
39 Certificate validation is a difficult problem. If certificate handling
40 is to be widely deployed in a variety of applications and environments,
41 the amount of processing an application needs to perform before it can
42 accept a certificate must be reduced. There are a variety of
43 applications that can use public key certificates but are burdened by
44 the overhead of validating the certificates when all the application
45 really wants is the public key and name from the certificate, and a
46 determination of whether or not the certificate may be used for a
47 particular purpose. There are other applications that can perform
48 certificate path validation but have no reliable method of obtaining a
49 current chain to a trusted certificate.
51 1.1 SCVP overview and requirements
53 The primary goals of SCVP are to make it easier for applications to
54 deploy systems using a PKI and to allow centralization of administering
55 PKI policies. Parts of SCVP can be used by clients that do much of the
56 PKI processing themselves and simply want a useful but untrusted server
57 that will collect information for them. Other parts can be used by
58 clients that have complete trust in the server to both offload the work
59 of certificate validation and to ensure that policies are enforced in a
60 consistent fashion across an enterprise.
62 Untrusted SCVP servers can give client the certificate chains needed
63 for path validation. They can also give clients revocation information
64 such as CRLs and OCSP responses that the client can use in the client's
65 path validation. These services can be valuable to client systems that
66 do not include the protocols needed to find and download all of the
67 intermediate certificates, CRLs, and OCSP responses needed for the
68 client to perform complete path validation.
70 Trusted SCVP servers can perform full certificate validation for the
71 client. If a client uses these services, it inherently trusts the SCVP
72 server as much as it would its own path validation software (if it
73 contained such software). There are two main reasons that a client may
74 want to trust such an SCVP server:
76 - The client does not want to incur the overhead of including path
77 validation software and running it for each certificate it receives.
79 - The client is in an enterprise that wants to centralize its PKI
80 validation policies, such as which root certificates are trusted and
81 which types of policy checking are performed during path validation.
83 1.2 Terminology
85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
87 document are to be interpreted as described in [MUSTSHOULD].
89 1.3 Open Issues
91 The following is a list of issues that were raised on earlier versions
92 of this document that have not been fully dealt with here. Comments on
93 these issues are particularly welcome.
95 - Extensions can be marked as critical. The usefulness and problems of
96 criticality have been long debated and there has not been a great deal
97 of consensus. In SCVP, marking a request extension as critical says to
98 the server "don't give me an answer unless you understand this
99 extension", and marking a response extension as critical says "don't
100 use this response unless you understand this extension". Without the
101 critical bit in the extensions, either the semantics of extensions
102 would have to be changed to essentially say "all extensions are
103 critical" (which is overkill for some extensions that might really be
104 optional), or the semantics would have to be changed to say "you can
105 never rely on the other party understanding an extension", which would
106 limit the usefulness of some extensions.
108 - All responses are signed. There may be cases where the server
109 doesn't want to sign the responses, such as on messages that
110 are only error responses, or where the message is travelling over a
111 medium that is already known to be secure.
113 2. Protocol
115 The SCVP protocol uses a simple request-response model. That is, a SCVP
116 client creates a single request and sends it to the server; the server
117 creates a single response and sends it to the client. Typical use of
118 SCVP is expected to be over HTTP, and possibly email. This document
119 registers MIME types for SCVP requests and responses.
121 3. Requests
123 A SCVP client's request to the server MUST be a single FullRequest
124 item. The FullRequest item contains the entire request. A FullRequest
125 item is carried in an application/scvp-request MIME body part.
127 3.1 FullRequest
129 The FullRequest item encapsulates the client's request. The FullRequest
130 item contains a PSRequest item, and an optional RequestSignature item.
132 3.2 PSRequest
134 The PSRequest item contains the part of the client's request.
135 The PSRequest item
136 contains a Version item, a Query item, a TypesOfCheck item, and a
137 WantBack item. It can also contain an optional RequestNonce item and
138 an optional ReqExtensions item. (The "PS" in PSRequest means "possibly
139 signed".)
141 A signed request can be used to authenticate the client to the
142 server and for non-repudiation of the client's request, such as for
143 accounting purposes. A server might require all requests to be signed
144 if the server did not want to respond to request unless they were from
145 authenticated clients. A server might want to allow unsigned requests
146 if the server is authenticating in some other fashion (such as by
147 IP address).
149 In this specification, the item(s) in the Query item are certificates.
150 The TypesOfCheck item tells the server what types of checking it should
151 do on the item(s) in the Query item. The WantBack item tells the server
152 what the client wants to know about the item(s). ReqExtensions in the
153 PSRequest item are used to extend the request, such as to request a
154 different type of item.
156 3.3 Version
158 The Version item tells the version of SCVP used in a request or a
159 response. The value of the Version item for this specification is 1.
161 3.4 Query
163 The Query item specifies the object of the request. One type of object
164 is defined in this specification: CertsQuery. (Other types of queries
165 might be specified in the future.) The CertsQuery is a request for
166 information on one or more certificates. A CertsQuery contains a list
167 of certificates, and can also contain zero or one of each of the
168 following items: ValidityTime, IntermediateCerts, TrustedCerts,
169 RevocationInfo, PolicyID, ConfigurationIdentifier, and QueryExtensions.
171 The list of certificates in the Query item tells the server the
172 certificate(s) the client wants a reply for. The optional ValidityTime
173 item tells the time at which the client wants to know about. The
174 optional IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, and
175 ConfigurationIdentifier items tell the server how to process the
176 request.
178 3.5 CertBundle
180 The CertBundle item contains one or more Certs. The order of
181 the Cert(s) in the bundle is not important.
183 3.6 Cert
185 The Cert item contains a complete certificate. The Cert item
186 contains an identifier for the type of certificate and the octets of
187 the certificate itself. One type of certificate, for PKIX [PKIX], is
188 defined, but other types of certificates (such as for OpenPGP
189 [OpenPGP]) may be defined in the future.
191 3.8 QueryExtensions
193 The QueryExtensions item specifies a list of extensions to the SCVP
194 protocol, for example to request additional information about the
195 certificate(s) in the CertsQuery. The QueryExtensions item contains a
196 sequence of Extension items, each of which contain an ExtnID item,
197 a Critical item, and an ExtnValue item.
199 3.9 ExtnID
201 The ExtnID item is an identifier for the extension. It contains
202 the OID of the extension.
204 3.10 Critical
206 The Critical item tells whether the extension is critical. The
207 values for the item are:
209 False Not critical
210 True Critical
212 In a request, if the Critical item is true, the server MUST
213 NOT process the request unless it understands the extension. In a
214 reply, if the Critical item is true, the client MUST NOT
215 process the reply unless it understands the extension.
217 3.11 ExtnValue
219 The ExtnValue item gives the value of an extension. It
220 contains a sequence of octets.
222 3.12 IntermediateCerts
224 The IntermediateCerts item specifies to the server the intermediate
225 certificates that the server MAY use when forming a certificate chain.
226 The certificates in the IntermediateCerts item can be used by the
227 server in addition to any other certificates that the server knows of
228 when building chains. The IntermediateCerts item contains a list of
229 certificates. The certificates in the IntermediateCerts MUST NOT be
230 self-signed certificates.
232 The purpose of the IntermediateCerts item is to help the server create
233 validation chains.
235 3.13 TrustedCerts
237 The TrustedCerts item specifies to the server the trusted certificates
238 that the server MUST use. If a TrustedCerts item is included in a
239 CertsQuery item, the server MUST NOT use any certificate chain anchors
240 other than the certificates in the TrustedCerts item when forming a
241 certificate chain for validation. The TrustedCerts item contains a
242 CertBundle item.
244 3.14 RevocationInfo
246 The RevocationInfo item specifies to the server revocation information
247 such as CRLs and OCSP [OCSP] responses that the server MAY use when
248 validating certificate chains. The purpose of the RevocationInfo item
249 is to provide revocation information to the server that the server may
250 not have access to, such as an OCSP response that the client received
251 along with the certificate. Note that the information in the
252 RevocationInfo item might not be used by the server, such as if the
253 information is for certificates that the server does not use in chain
254 building.
256 The types of revocation proof that can be provided are:
257 - CRL
258 - OCSP response
260 [[[Need to specify the format of the extensions for both CRLs and
261 for OCSP responses.]]]
263 3.15 PolicyID
265 The PolicyID item specifies to the server the policy ID that the server
266 MUST use when forming a certificate chain. The PolicyID item contains
267 a URL that, when resolved, defines the policy.
269 3.16 ConfigurationIdentifier
271 The ConfigurationIdentifier item tells the server the SCVP options that
272 the client wants the server to use. The client can use this option
273 instead of specifying other SCVP configuration such as PolicyID,
274 TrustedCerts, RevocationInfo, and so on. The value of this item is
275 determined by private agreement between the client and the server and
276 is not specified in this document. For example, the value might be the
277 hash of some set of options, or it might be a short identifier for a
278 common set of options. Further, the server might want to have
279 identifiers that indicate that some settings are used in addition to
280 others given in the request; in this way, the configuration identifier
281 might be a shorthand for some SCVP options.
283 3.17 TypesOfCheck
285 The TypesOfCheck item describes the kind of checking that the client
286 wants the server to do on the certificate(s) in the Query item. If the
287 TypesOfCheck item is given in a request, it can contain one or more
288 types of checks. For each type of check specified in the request, the
289 server MUST perform all the checks requested, or return an error.
291 The types of checks are:
292 - Path validation to a trusted root
293 - Revocation status
294 Note that revocation status check inherently includes path validation.
296 3.18 WantBack
298 The WantBack item describes the kind of information the client wants
299 from the server for the certificate(s) in the Query item. If the
300 WantBack item is given in a request, it can contain one or more types
301 of information. For each type of information specified in the request,
302 the server MUST return information on what it found during the check.
304 The types of information that can be requested are:
305 - Certificate chain used to validate the certificate
306 - Proof of revocation status
308 For example, a request might include a TypesOfCheck item that does not
309 specify path validation, and include a WantBack item that specifies the
310 certificate chain used to validate. The response would not include a
311 status for the validation, but would include a certificate chain that
312 the server thinks might validate. This set of options might be used by
313 a client that wants to do its own path validation.
315 3.19 ValidityTime
317 The ValidityTime indicates the time for which the client wants the
318 information to be relevant. Not specifying a ValidityTime means that
319 the server should use the current time. For example, when asking for
320 validation of a certificate, the client might ask "was this certificate
321 valid at this time". The information in the CertReply item in the
322 response MUST be formatted as if the server created the response at the
323 time indicated in the ValidityTime, if the server doesn't have
324 historical information about that time, it MAY either return an error
325 or return information for a later time. A client MUST be able to handle
326 responses that have ThisUpdate items that are later than the requested
327 ValidityTime.
329 3.20 RequestNonce
331 The RequestNonce item is an identifier generated by the client for the
332 request; the server MUST return the same RequestNonce in the signed
333 part of the server's response. The RequestNonce item is simply a
334 sequence of octets. The client SHOULD include a RequestNonce item in
335 every request to prevent an attacker acting as a man-in-the-middle from
336 replaying old responses from the server. The value of the nonce SHOULD
337 change with every request sent from the client.
339 3.22 RequestSignature
341 The RequestSignature item is the signature of the PSRequest item. The
342 details of how a RequestSignature is computed is defined in the
343 specific sections which describe how a request/response is represented
344 in various formats.
346 4. Responses
348 A SCVP server's response to the client MUST be a single FullResponse
349 item. The FullResponse item contains the entire response. A
350 FullResponse item is carried in an application/scvp-response MIME body
351 part.
353 4.1 FullResponse
355 The FullResponse item encapsulates the server's response. The
356 FullResponse item contains a PSResponse item and an optional
357 ResponseSignature item.
359 4.2 PSResponse
361 The PSResponse item contains the part of the server's response that is
362 signed by the ResponseSignature item. The item contains a Version
363 item, a ProducedAt item, a ResponseStatus item, and a RequestHash
364 item. The item can also contain an optional ReplyObjects item, an
365 optional RequestNonce item, and an optional RespExtensions item. The
366 PSResponse item MUST contain exactly one CertReply item for each
367 certificate requested in the request. The RequestNonce item MUST be
368 included if the request had a RequestNonce item.
370 4.3 ProducedAt
372 The ProducedAt item tells the time at which the whole response was
373 produced. The ProducedAt item represents the date at UTC.
375 4.4 ResponseStatus
377 The ResponseStatus item gives status information to the client about
378 its request. The ResponseStatus item has a numeric status code and an
379 optional string that is a sequence of characters from the ISO/IEC
380 10646-1 character set encoded with the UTF-8 transformation format
381 defined in [UTF8].
383 The optional string may be used to transmit status information, but it
384 is optional. The client MAY choose to display the string to the client.
385 However, because there is no way to know the languages understood by
386 the user, the string may be of little or no use to them.
388 The complete list of status codes for the ResponseStatus item is:
390 0 The request was fully processable
391 1 The request included unrecognized items; continuing
393 10 Too busy; try again later
395 20 The structure of the request was wrong
396 21 The version of request is not supported by this server
397 22 The request included unrecognized items; aborting
398 23 The key given in the RequestSignature is not recognized
399 24 The signature did not match the body of the request
400 25 The encoding was not understood
401 26 The request was not authorized
403 4.4a RequestHash
405 The RequestHash item is the SHA-1 hash of the PSRequest item. The
406 RequestHash item serves the following purposes:
408 - It helps a client know that the request was not maliciously modified
409 when the client gets the response back
411 - It allows the client to associate a response with a request when
412 using connectionless protocols
414 The purpose of the RequestHash is not for authentication of the
415 client.
417 The server MUST return the RequestHash item in the response.
419 4.5 ReplyObjects
421 The ReplyObjects item returns objects to the client. In this
422 specification, the ReplyObjects item is always a CertReply, which tells
423 the client about a single certificate from the request. The CertReply
424 item contains a Cert item identifying the certificate, a
425 ReplyStatus item, a ThisUpdate item, and a NextUpdate item. There may
426 also be the following optional items: ValidationStatus,
427 RevocationStatus, PublicKey, CertSubject, ValidationChain,
428 RevocationProof, and SingleReplyExtensions.
430 The presence or absence of the ValidationStatus, RevocationStatus,
431 PublicKey, CertSubject, ValidationChain, and RevocationProof items in
432 the CertReply item is controlled by the TypesOfCheck, and WantBack
433 items in the request. A server MUST include one of the above items for
434 each related item requested in the TypesOfCheck, and WantBack items.
436 4.6 ReplyStatus
438 The ReplyStatus item gives status information to the client about the
439 request for the specific certificate. Note that the ResponseStatus item
440 is different than the ReplyStatus item. The ResponseStatus item is the
441 status of the whole request, while the ReplyStatus item is the status
442 for the individual certificate.
444 The complete list of status codes for the ReplyStatus item is:
446 0 Success: a definitive answer follows
447 1 Failure: the certificate type is not recognized
448 2 Failure: an item wanted in TypesOfCheck is not recognized
449 3 Failure: an item wanted in WantBack is not recognized
450 4 Failure: the certificate was malformed
451 5 Failure: the mandatory PolicyID is not recognized
452 6 Failure: the ConfigurationIdentifier is not recognized
453 7 Failure: unauthorized request
455 Status code 4 is used to tell the client that the request was properly
456 formed but the certificate in question was not. This is useful to
457 clients that cannot parse a certificate.
459 4.7 ThisUpdate
461 The ThisUpdate item tells the time at which the information in the
462 CertReply was correct. The ThisUpdate item represents the date as
463 UTC.
465 4.8 NextUpdate
467 The NextUpdate item tells the time until which the server expects the
468 information in the CertReply to be valid. The NextUpdate item
469 represents the date at UTC. [[[Is there a desire for another item that
470 says "the server takes liability for this response up to this
471 particular time?]]]
473 4.9 ReplyTypesOfCheck
475 The ReplyTypesOfCheck contains the responses to the client's
476 TypesOfCheck item in the request. It has the same form as the
477 Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match
478 the OIDS in the TypesOfCheck item.
480 The value for path validation to a trusted root, {type-arc 0}, can be
481 one of the following:
483 0 Valid
484 1 Not valid
485 2 Unknown
487 The value for the revocation status, {type-arc 1}, can be one of the
488 following:
490 0 Good
491 1 Revoked
492 2 Unknown
494 4.10 ReplyWantBack
496 The ReplyWantBack contains the responses to the client's WantBack item
497 in the request. It has the same form as the Extensions item, and the
498 OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack
499 item.
501 The value for the certificate chain used to validate the certificate
502 in the request, {want-arc 1}, is a CertBundle item.
504 The value for the proof of revocation status, {want-arc 2}, is a
505 RevocationProof item.
507 4.11 RevocationProof
509 The RevocationProof item gives the client the proof that the server
510 used to check revocation. The structure of the RevocationProof item is
511 the same as an Extensions item. The OIDs in the RevocationProof item
512 are the same as those in the RevocationInfo item.
514 4.12 ResponseSignature
516 The ResponseSignature item is the signature of the PSResponse item.
518 The client SHOULD check the signature on every signed message it
519 receives from the server. In order to check the signature, the client
520 MUST know and rely on the public signing key of the server. The client
521 could have obtained the server's public key through an out-of-band
522 mechanism of direct trust or through a certificate that chains to a
523 root that the client trusts to delegate this type of authority.
525 5. ASN.1 Syntax for SCVP
527 This section defines the syntax for SCVP messages. The semantics for
528 the messages are defined in sections 2, 3, and 4.
530 5.1 Signatures in ASN.1
532 Signatures in ASN.1 are done over the DER encoding of the
533 PSRequest/PSResponse item. The Name is the distinguished name of the
534 signer. The SignatureAlgorithm is the
535 algorithm used to sign the request, and a SignatureBits item that is
536 the signature itself. The signature may also contain an
537 optional CertBundle that represents a chain of certs to verify the key used
538 to sign the request.
540 5.1.1 SignatureAlgorithm
542 The SignatureAlgorithm identifies the algorithm used to sign a request
543 or response. The SigningAlgorithm item contains the OID of the
544 algorithm and any necessary parameters for the algorithm.
546 5.1.2 SignatureBits
548 The SignatureBits item holds the octets of a signature. The structure
549 of the SignatureBits item is determined by the value of the
550 SignatureAlgorithm item.
552 5.2 ASN.1 Module definition
554 SCVP DEFINITIONS EXPLICIT TAGS ::=
556 BEGIN
558 IMPORTS
560 -- Directory Authentication Framework (X.509)
561 Certificate, AlgorithmIdentifier
562 FROM AuthenticationFramework { joint-iso-itu-t ds(5)
563 module(1) authenticationFramework(7) 3 }
565 -- PKIX Imports
566 Name, Extensions,
567 FROM PKIX1Explicit88 {iso(1) identified-organization(3)
568 dod(6) internet(1) security(5) mechanisms(5) pkix(7)
569 id-mod(0) id-pkix1-explicit-88(1)};
571 FullRequest ::= SEQUENCE {
572 psRequest PSRequest,
573 requestSignature [0] Signature OPTIONAL
574 }
576 PSRequest ::= SEQUENCE {
577 version INTEGER,
578 query Query,
579 typesOfCheck TypesOfCheck,
580 wantBack WantBack,
581 requestNonce [1] OCTET STRING OPTIONAL,
582 reqExtensions [2] Extensions OPTIONAL
583 }
585 Query ::= CHOICE {
586 certsQuery [0] CertsQuery
587 }
589 CertsQuery ::= SEQUENCE {
590 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert,
591 validityTime [0] GeneralizedTime OPTIONAL,
592 intermediateCerts [1] SEQUENCE SIZE (1..MAX) OF Cert OPTIONAL,
593 trustedCerts [2] CertBundle OPTIONAL,
594 revocationInfo [3] Extensions OPTIONAL,
595 policyID [4] UTF8String OPTIONAL,
596 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
597 queryExtensions [6] Extensions OPTIONAL
598 }
600 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert
602 Cert ::= CHOICE {
603 pkixCert [0] Certificate
604 }
606 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
608 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
610 Signature ::= SEQUENCE {
611 signerName Name,
612 signatureAlgorithm AlgorithmIdentifier,
613 signatureBits BIT STRING,
614 certs [0] CertBundle OPTIONAL
615 }
617 FullResponse ::= SEQUENCE {
618 psResponse PSResponse,
619 responseSignature [0] Signature OPTIONAL
620 }
622 PSResponse ::= SEQUENCE {
623 version INTEGER,
624 producedAt GeneralizedTime,
625 responseStatus ResponseStatus,
626 requestHash OCTET STRING,
627 replyObjects [0] ReplyObjects OPTIONAL,
628 requestNonce [2] OCTET STRING OPTIONAL,
629 respExtensions [3] Extensions OPTIONAL
630 }
632 ResponseStatus ::= SEQUENCE {
633 statusCode INTEGER,
634 errorMessage [0] UTF8String OPTIONAL
635 }
637 ReplyObjects ::= CHOICE {
638 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply
639 }
641 CertReply ::= SEQUENCE {
642 cert Cert,
643 replyStatus ReplyStatus,
644 thisUpdate GeneralizedTime,
645 nextUpdate GeneralizedTime,
646 replyTypesOfCheck [0] Extensions OPTIONAL,
647 replyWantBack [1] Extensions OPTIONAL,
648 singleReplyExtensions [2] Extensions OPTIONAL
649 }
651 ReplyStatus ::= ENUMERATED {
652 success (0),
653 certTypeUnrecognized (1),
654 typeOfCheckUnrecognized (2),
655 wantBackUnrecognized (3),
656 certMalformed (4),
657 policyIDUnrecognized (5),
658 configInfoUnrecognized (6),
659 unauthorizedRequest (7)
660 }
662 -- Need to include type-arc, want-arc, and revinfo-arc
664 END
666 6. XML Syntax for SCVP
668 This section defines the syntax for SCVP messages. The semantics for
669 the messages are defined in sections 2, 3, and 4.
671 TODO: We need to import the XML DSig data into our DTD. We also need
672 to provide more information about the format of the elements which map
673 to PCDATA.
675 Note: this is the second attempt at XML for SCVP. We invite any comments
676 on it.
678 6.1 Signatures in XML
680 Signatures are done using [XMLDSIG].
682 6.2 Namespaces
684 The XML namespace [XML-ns] URI that MUST be used by implementations of
685 this (dated) specification is:
687 xmlns="http://www.ietf.org/pkixwg/01/scvp"
689 6.3 XML Request/Response syntax
691
694
696
699
700
706
709
711
713
722
724
726
728
730
732
734
736
738
740
742
744
746
748
750
752
754
756
758
760
762
764
767
769
777
780
782
785
787
789
791
793
795
797
805
807
809
811
813
814
824
826 6.3 Example of XML syntax
828
830
832
833
834 1
835
836
837
838
839
840 MIICEzCCAb0CAgfYMA0GCSqGSIb3D
841 QEBBAUAMIGTMQswCQYDVQQGEwJLTz
842 . . .
843 oeedsN6iA4IhpA4Ev2rWiM92OoKag
844 UvVGaQoBuDkz7JfYNw==
845
846
847
849
850 19991232235959
851
852
854
855
856
857 MIICEzCCAb0CAgfYMA0GCSqGSIb3D
858 QEBBAUAMIGTMQswCQYDVQQGEwJLTz
859 . . .
860 oeedsN6iA4IhpA4Ev2rWiM92OoKag
861 UvVGaQoBuDkz7JfYNw==
862
863
865
867
868
870
871 1.3.5.5.5.2.5.2
872
874
875 1.3.5.5.5.2.5.2
876
877 2888475218934
878
879
880 1.5.4.5.9.12.1
881 192812
882
883
885
887
888
889
891
893
894
895
897
898
899
901 a23bcd43
902
903
904 dd2323dd
905
906
907
908 C=US, ST=Illinois, L=Chicago, O=Aromatic
909 Penguin Playing Basketball, OU=Certificate
910 Authority, CN=www.ceramic.com
911 2007
912
913
914 MIICITCCAcsCAgfXMA0GCSqGSIb3DQEBBAUAMIGaMQswCQYDVQQG
915 EwJVUzERMA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNh
916 . . .
917 bD2d2MixUSENihcgGbCEikUpNrMREO/eYkyKsiqmzAxlr3Tu/eKB
918 NBeu
919
920
921
922
923
925 TODO: Need to add an example of a response
927 7. Security Considerations
929 A client that trusts a server's responses for validation of
930 certificates inherently trusts that server as much as it would trust
931 its own validation software. This means that if an attacker compromises
932 a trusted SCVP server, the attacker can change the validation
933 processing for every client that relies on that server. Thus, an SCVP
934 server must be protected at least as well as the weakest root server
935 that the SCVP server trusts.
937 If the client does not check the signature on the response, a
938 man-in-the-middle attack could fool the client into believing modified
939 responses from the server, or responses to questions the client did not
940 ask. This attack does not affect the usefulness of some responses (such
941 as a response that returns a certificate path that the client will
942 validate itself) but does affect things such as a validation response.
944 If the client does not include a RequestNonce item, or if the client
945 does not check that the RequestNonce in the reply matches that in the
946 request, an attacker can replay previous responses from the server.
947 This attack can also be mounted, even with signed requests, if the
948 server does not keep track of previous RequestNonce items.
950 If the server does not require some sort of authorization (such as
951 signed requests), an attacker can get the server to reply to arbitrary
952 requests. Such responses may give the attacker information about
953 weaknesses in the server or about the timeliness of the server's
954 checking. This information may be valuable for a future attack.
956 A. References
958 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
959 Levels", RFC 2119.
961 [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560.
963 [OpenPGP] "OpenPGP Message Format", RFC 2440.
965 [PKIX] "PKIX Certificate and CRL Profile", RFC 2459.
967 [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April
968 1995.
970 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
972 [XMLDSIG] NEED THE REFERENCE
974 B. Acknowledgments
976 The lively debate in the PKIX Working Group also had a significant
977 impact on the types of items described in this protocol. Denis Pinkas
978 suggested some additional requirements for the protocol, and Mike Myers
979 helped point out sections that needed clarification.
981 C. Changes Between Versions of This Document
983 C.1 Differences between -00 and -01
985 1: Rewrote to both narrow focus and to explain the goals more fully.
987 1.1: Removed second paragraph.
989 2: Removed the discussion of the two syntaxes.
991 3: Reorganized the section to put the Extensions items after the
992 CertsQuery items. The section numbers below are from the -00 draft.
993 Throughout the section, made RequestHash mandatory instead of optional.
994 Added RevocationInfo item. Changed CertID to CertHash throughout.
995 Fixed the names of the parts of the signature to match the text.
997 3.1: Split the item into a TBSRequest followed by the hash and/or
998 signature. Changed the order of the extensions item so that all the
999 optional items were together. Changed CertsQuery into Query. Added the
1000 ValidityTime item.
1002 3.3: Redefined Extension to be Extensions to be more similar to
1003 Extensions in PKIX. Other wording changes.
1005 3.5: Gave more explanation for the ExtensionCritical bit, and made
1006 the values boolean. Note that this item may disappear, depending
1007 on discussion of the open issue on it.
1009 3.7: Changed CertsQuery into Query and described the one defined
1010 instance as CertsQuery. Moved the TypesOfCheck and WantBack from the
1011 Query and up one level to the TBSRequest.
1013 3.9: Removed OpenPGP cert, but allowed for it to be added back in the
1014 future.
1016 3.10: Removed OpenPGP cert hash, but allowed for it to be added back in
1017 the future.
1019 3.11 Made TypesOfCheck OIDs.
1021 3.12: Made WantBack OIDs. Removed the public key and the names.
1023 3.10: Added sentence about when a client might include a CertHash item
1024 in the TrustedRoots.
1026 3.13: Clarified use of IntermediateCerts
1028 3.18: Added wording that the RequestHash should not be used for
1029 authentication.
1031 3.19: Changed wording to make it clear that RequestSignature was needed
1032 only for authentication of the client.
1034 3.23: Clarified purpose of KeyID.
1036 4: The section numbers below are from the -00 draft. Throughout the
1037 section, made returning the RequestHash mandatory because it is now
1038 mandatory in the request.
1040 4.1: Split the item into a TBSResponse followed by the hash and/or
1041 signature. Made ResponseSignature mandatory. Made the items returned in
1042 the form of Extensions to match the fact that TypesOfCheck and WantBack
1043 are now sequences of OIDs.
1045 4.3: Made the status code a single number.
1047 4.4 Removed the subject names and public keys. Added NextUpdate.
1049 4.10: Clarified that CertSubject for PKIX certs must contain both the
1050 subject name and the subjectAltName.
1052 4.13: Made ResponseSignature mandatory; this might be changed back to
1053 optional for some types of responses in a future revision of the spec.
1054 Added a discussion of how the client can get the server's signing key.
1056 Old 5: Removed tiny syntax, renumbered old 6 to 5.
1058 5: Added note about semantics in 2-4.
1059 Split FullRequest into FullRequest and TBSRequest.
1060 Moved the extensions item in FullRequest.
1061 Changed the certsQuery to Query.
1062 Move TypesOfCheck and WantBack up to TBSRequest.
1063 Made TypesOfCheck and WantBack SEQUENCE of OIDs.
1064 Added ValidityTime.
1065 Changed "CertID" to "CertHash".
1066 Made the status code a single number.
1067 Added reminder in CertItem about full certs.
1068 Changed order of Signature items.
1069 Split FullResponse into FullResponse and TBSResponse.
1070 Added ReplyTypesOfChecks and ReplyWantBack items.
1071 Added Extensions item and sub-items.
1073 7: Updated to reflect mandatory RequestHash and ResponseSignature.
1074 Added explicit words about compromise of the SCVP server. Removed the
1075 first paragraph because it was confusing and will be fixed in later
1076 versions of the draft.
1078 A: Added reference to OCSP.
1080 D: Updated.
1082 C.2 Difference between -01 and -02
1084 Abstract: Updated to include design goals.
1086 Throughout: Changed TBSRequest to PSRequest. Changed UsageID to
1087 PolicyID. Changed Greenwich Mean Time to UTC.
1089 1.2: Changed wording to match RFC 2119.
1091 1.3: Removed first open issue (cert hashes) because we removed cert
1092 hashes. Removed third open issue (optional response signing) because
1093 the draft now clarifies which responses must be signed and which ones
1094 don't. Added new open issue (making signatures on responses optional).
1096 3.1: Removed the RequestHash from the request.
1098 3.2: Removed the RequestHash from the request. Added explanation of
1099 PSRequest name. Added SignerName here.
1101 3.4: Added note about other types of queries being added in the future.
1103 3.5: Removed CertHash.
1105 3.7: Removed the CertHash item. Filled in the hole that would have been
1106 created with SignerName from below.
1108 3.10: Minor edit to last line.
1110 3.12: Removed most of the second paragraph because it was confusing.
1112 3.14: Removed the arc stuff.
1114 3.15: Made the PolicyID be a URL instead of an OID.
1116 3.17: Removed the arc stuff. Also added last sentence after the list.
1118 3.18: Removed the arc stuff.
1120 3.19: Removed the surperfluous NextUpdate from the last sentence.
1121 Detailed what no ValidityTime request means. Changed what should happen
1122 if the client requests information for a time that the server does not
1123 have.
1125 3.21: Changed last sentence to indicate that the RequestHash is only
1126 returned in the response, not sent in the request.
1128 3.22: Removed the last sentence because the RequestHash is only
1129 returned in the response, not sent in the request. Moved the second
1130 paragraph up to 3.2 to make it clearer why someone might or might not
1131 sign their request. Got rid of the optional KeyID. Removed the
1132 SignerName.
1134 3.23: Moved SignerName up in the document to 3.7. Renumbered the rest
1135 of this section.
1137 3.26: Got rid of KeyID item.
1139 4.2: Added SignerName here.
1141 4.4: Got rid of 11 and 12 and made the description of 10 more sensible.
1142 Changed 25 to "encoding not understood".
1144 4.5: Removed the last sentence because it was confusing.
1146 4.9: Got rid of "temporarily unknown".
1148 4.12: Made the response signature optional in the first sentence of the
1149 second paragraph. Got rid of KeyID. Removed the SignerName.
1151 5: Removed RequestHash from FullRequest. Removed CertItem and made
1152 CertBundle a SEQUENCE OF Cert. Changed type of policyID to UTF8string
1153 to hold the URL. Got rid of KeyID. Moved signerName out of Signature
1154 and into PSRequest and TBSResponse, and made it optional.
1156 6: Added the XML syntax and example.
1158 7: Removed the second paragraph because it dealt with RequestHash in
1159 the request.
1161 C.3 Difference between -02 and -03
1163 1. Changed TBSResponse and TBSRequest to PSResponse and
1164 PSRequest. Made signatures optional in both requests and responses.
1166 2. Added a tag to the optional signatures in both requests and
1167 responses.
1169 3. Changed RevocationInfos to RevocationInfo.
1171 4. Removed CertHash completely.
1173 5. Simplified section 3.5, since FullCert has gone away
1175 6. Replaced section 3.6 to talk about Cert, rather than FullCert
1177 7. Replaced ExtensionParameter with ExtensionValue in Section 3.11.
1179 8. Made sure that all SEQUENCE OF are SEQUENCE SIZE (1..MAX) OF
1181 9. Import Extension and used the same definition for Extension as in
1182 RFC2459
1184 10. Replace "trusted root" with "trusted certificate", because a
1185 server or client might decide to put its trust in a certificate that
1186 might not be self-signed. Replaced trustedRoot with trustedCert.
1188 11. Fixed once occurance of definition of requestNonce
1190 12. Removed scvp, scvpReq and scvpResp tags in the XML.
1192 13. Removed the last 2 sentences of the second paragraph Section 3.4
1194 14. Changed last sentence of section 3.13, since you have have multiple
1195 cert chains for a certificate even if there is no cross certification.
1197 15. Changed last sentence of section 3.17.
1199 16. Moved section 3.21 to the response section - 4.4a. We need to
1200 renumber all sections when we are close to being done.
1202 17. Added a default value for the attribute value of ReplyStatus in
1203 the XML.
1205 18. Added IMPORTS to the ASN.1 module.
1207 19. Gave the extensions in different places different names.
1209 20. Changed the way criticality is specified for Extension in XML
1211 21. Added the mime type registration requests
1213 22. Added appendix E and moved Author Information to appendix F
1215 23. Moved signerName from the PSRequest and PSResponse to the
1216 signature part.
1218 24. Removed the second paragraph in section 3.13.
1220 25. Changed a line in section 3.14, first para (about where a client
1221 may have obtained an OCSP response to send to the SCVP server).
1223 26. Got rid of the multiple places where we say what is signed by the
1224 RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also
1225 simplified the definition of the RequestSignature and
1226 ResponseSignature in sections 3 and 4. The should be defined in detail
1227 in the encoding sections.
1229 D. MIME Registrations
1231 D.1 application/scvp-request
1233 To: ietf-types@iana.org
1234 Subject: Registration of MIME media type application/scvp-request
1236 MIME media type name: application
1238 MIME subtype name: scvp-request
1240 Required parameters: None
1242 Optional parameters: None
1244 Encoding considerations: binary or XML
1246 Security considerations: Carries a request for information. This
1247 request may optionally be cryptographically signed.
1249 Interoperability considerations: None
1251 Published specification: IETF PKIX Working Group Draft on Simple
1252 Certificate Validation Protocol - SCVP
1254 Applications which use this media type: SCVP clients
1256 Additional information:
1258 Magic number(s): None
1259 File extension(s): .SCQ
1260 Macintosh File Type Code(s): none
1262 Person & email address to contact for further information:
1263 Ambarish Malpani
1265 Intended usage: COMMON
1267 Author/Change controller:
1268 Ambarish Malpani
1270 D.2 application/scvp-response
1272 To: ietf-types@iana.org
1273 Subject: Registration of MIME media type application/scvp-response
1275 MIME media type name: application
1277 MIME subtype name: scvp-response
1279 Required parameters: None
1281 Optional parameters: None
1282 Encoding considerations: binary or XML
1284 Security considerations: Carries a cryptographically signed response
1286 Interoperability considerations: None
1288 Published specification: IETF PKIX Working Group Draft on Simple
1289 Certificate Validation Protocol - SCVP
1291 Applications which use this media type: SCVP servers
1293 Additional information:
1295 Magic number(s): None
1296 File extension(s): .SCS
1297 Macintosh File Type Code(s): none
1299 Person & email address to contact for further information:
1300 Ambarish Malpani
1302 Intended usage: COMMON
1304 Author/Change controller:
1305 Ambarish Malpani
1307 E. SCVP data format
1309 E.1 SCVP over HTTP
1311 This section describes the formatting that will be done to the
1312 request and response to support HTTP.
1314 E.1.1 Request
1316 HTTP based SCVP requests can the POST method to
1317 submit their requests. Where privacy is
1318 a requirement, SCVP transactions exchanged using HTTP MAY be
1319 protected using either TLS/SSL or some other lower layer protocol.
1321 An SCVP request using the POST method is constructed as follows: The
1322 Content-Type header MUST have the value "application/scvp-request"
1323 while the Content-Length header MUST be present and have the exact
1324 length of the request. The body of the message is the binary value
1325 of the DER encoding of the FullRequest, or XML encoding of
1326 FullRequest. Other HTTP headers MAY be present and MAY
1327 be ignored if not understood by the requestor.
1329 E.1.2 Response
1331 An HTTP-based SCVP response is composed of the appropriate HTTP
1332 headers, followed by the binary value of the DER encoding of the
1333 FullResponse or XML encoding of FullResponse. The Content-Type
1334 header MUST have the value "application/scvp-response". The
1335 Content-Length header MUST be present and specify
1336 the length of the response. Other HTTP headers MAY be present and MAY
1337 be ignored if not understood by the requestor.
1339 F. Author Contact Information
1341 Ambarish Malpani
1342 ValiCert, Inc.
1343 339 N. Bernardo Ave.
1344 Mountain View, CA 94043
1345 ambarish@valicert.com
1347 Paul Hoffman
1348 VPN Consortium
1349 127 Segre Place
1350 Santa Cruz, CA 95060 USA
1351 paul.hoffman@vpnc.org