idnits 2.17.1 draft-gutmann-cms-rtcs-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 1038 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.) ** There are 351 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (March 2004) is 7348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 470 ** Obsolete normative reference: RFC 2633 (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Obsolete normative reference: RFC 3126 (Obsoleted by RFC 5126) ** Obsolete normative reference: RFC 3369 (Obsoleted by RFC 3852) ** Downref: Normative reference to an Informational RFC: RFC 3379 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P.Gutmann 2 draft-gutmann-cms-rtcs-01.txt University of Auckland 3 Expires September 2004 March 2004 5 Real-time Certificate Status Facility for CMS - (RTCS) 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months and may 17 be updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet-Drafts as reference material or to cite them 19 other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2003). All Rights Reserved. 31 1. Abstract 33 This document describes how the Cryptographic Message Syntax may be used for 34 communicating certificate status information in a manner suitable for use with 35 CMS data and CMS-related messaging mechanisms such as S/MIME. 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 38 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 39 uppercase, as shown) are to be interpreted as described in [RFC2119], except 40 when they appear in ASN.1 constructs, in which case they follow [X.680] 42 2. Problem analysis 44 This section examines the problems that need to be solved by the protocol, and 45 provides a rationale for design decisions. Section 3 defines the protocol 46 based on the design decisions. 48 2.1 Overview 50 When the OCSP protocol was defined, the design was based on full compatibility 51 with CRL-based mechanisms and the use of a nonstandard message format 52 incompatible with the Cryptographic Message Syntax. This requires the use of 53 a complex means of certificate identification that has resulted in 54 interoperability problems among implementations, a design unsuited for high- 55 throughput, real-time operation, the inability to provide an unambiguous 56 certificate status response (the only thing that a CRL can say with certainty 57 is "revoked"), and an online responder tied to an offline mechanism (some CAs 58 issue CRLs only once or twice a day, even though they have an online, real- 59 time certificate store available). A more practical problem is that it makes 60 it impossible to implement an OCSP responder using a standard CMS toolkit or 61 implementation, or not based on CRLs, for example one that consults a 62 certificate database or in-memory hash table to determine the presence or 63 absence of a valid certificate. 65 Just as the original OCSP responses were designed for completely CRL- 66 compatible operation, this document specifies a response type that is designed 67 for real-time status operation, providing a response not from a stored CRL 68 using CRL-only mechanisms but directly from a live certificate store or in- 69 memory hash table. This allows the responder to provide extended information 70 not possible with CRLs, combined a high level of performance and CMS- 71 compatibility not possible with the original OCSP design. 73 In abstract terms, the responder is providing an implementation of an 74 authenticated dictionary D that responds to membership queries from relying 75 parties. An OCSP responder answers the question "Is x excluded from D?", 76 while an RTCS responder answers the question "Is x present in D?". 78 When returning a response, the responder is merely indicating that the queried 79 certificate is currently present in its set of valid certificates in a 80 standard CMS-compatible manner. It is purely an authenticated dictionary 81 service and does not verify the certificate in any way. Relying parties 82 requiring external verification services should use the PKIX standard 83 mechanisms for this [RFC3379] and not RTCS. Specifically, RTCS does not 84 provide, and should not be assumed to provide, any of the functionality of 85 DPD/DPV. It is purely a mechanism for running a high-performance CMS- 86 compatible certificate status responder directly from a CA certificate 87 store/in-memory table. 89 Some of the issues that need to be addressed in order to perform this task are 90 covered in the following subsections. 92 2.2 Use of standard/flexible data formats 94 The format used for OCSP responses is an incomplete reinvention of the 95 standard CMS format that lacks a number of CMS features, leading to various 96 implementation/deployment difficulties. For example, some responders need to 97 provide confidentiality protection for their responses, since returning an 98 indication that a certificate has been revoked may be interpreted as a 99 statement about the veracity of the organisation that owns the certificate, 100 leading to potential liability concerns (the same problem is faced by some 101 CAs, who have to password-protect or encrypt their CRLs). Similarly, some 102 users require confidentiality protection on requests in order to prevent 103 traffic analysis by outsiders, for the same reasons that protection of 104 responses is required. These operations are trivial to implement using the 105 standard CMS format, but impossible with the OCSP reinvention of CMS, 106 requiring the use of ad-hoc/proprietary extensions. 108 Responders that operate in resource-constrained environments (see section 2.6) 109 or that require high-throughput operation (see section 2.5) may choose to 110 authenticate their responses with a low-overhead MAC rather than a high- 111 overhead signature. Again, this is impossible with the OCSP format but 112 trivial with CMS. 114 Finally, CMS is the standard format for signed/encrypted/MAC'ed data. Using 115 this format rather than an incompatible reinvention of the format allows for 116 simple implementations based on existing code. In the case of the OCSP 117 specification, more than half the ASN.1 is dedicated to reinventing the CMS 118 message format; omitting this unnecessary step considerably simplifies the 119 specification and the task of implementation. 121 2.3 Certificate identification 123 OCSP defines a complex certificate identifier that takes portions of the 124 certificate, hashes some (making reference to the original value impossible), 125 doesn't hash others, and even requires a hash of data from other certificates 126 to be included as part of the identifier, making it impossible to query the 127 status of a single, standalone certificate. The OCSP identifier is also 128 incompatible with all existing identifiers, including the one traditionally 129 used by CMS. Real-world experience has shown that implementors have 130 considerable difficulty with this identifier, leading to interoperability 131 problems among implementations. 133 RTCS should therefore provide a simple, widely-accepted, universally- 134 applicable identifier for all certificates, regardless of their schema or 135 encoding. For compatibility with legacy implementations, it also provides a 136 CRL-compatible identifier, although there are some caveats attached to its use 137 (see section 3.1). 139 2.4 Returned status value 141 Because of its CRL-based origins, OCSP can only return a negative response. 142 For example, when fed a freshly-issued certificate and asked "Is this a valid 143 certificate", it can't say "Yes" (a CRL can only answer "revoked"), and when 144 fed an Excel spreadsheet it can't say "No" (the spreadsheet won't be present 145 in any CRL). More seriously, CRLs and OCSP are incapable of dealing with a 146 manufactured-certificate attack in which an attacker issues a certificate 147 claiming to be from a legitimate CA (since the legitimate CA never issued it, 148 it won't be in its CRL, therefore a blacklist-based system can't report the 149 certificate as invalid). This attack is made significantly easier by the 150 implicit universal cross-certification present in many web browsers, where any 151 CA can usurp any other CA's certificates. Even without this universal cross- 152 certification mechanism, standard practice for browsers when encountering an 153 unknown certificate is to enquire of the user "... do you want to trust 154 ?", where company_name is the company running the site the user 155 is connecting to. Since the certificate is a manufactured certificate being 156 used in a MITM attack, it won't be present on the CRL of the real CA, and 157 since it corresponds to the site that the user is connecting to, they are 158 unlikely to reject it. 160 The unclear-status problem interacts badly with the one in section 2.3 in that 161 an unknown response could mean anything from "I couldn't find a CRL for this 162 certificate" to "I don't know the status of this certificate" to "This may 163 well be a non-revoked certificate but your software and mine disagree over how 164 to generate the identifier", and there is no way to determine what the actual 165 problem is. 167 To resolve this issue, RTCS should provide a clear, unambiguous response to 168 any query, either "This certificate is definitely valid right now", "This 169 certificate is definitely not valid right now", or "The object you have 170 queried doesn't exist" (standard OCSP can't do any of these). 172 2.5 Lightweight/realtime operation 174 OCSP requires that every response from a responder be authenticated with a 175 signature, whether this is appropriate or not. In cases where high 176 transaction volumes need to be handled, the overhead of having to sign each 177 transaction can be prohibitive (this is one of the few areas in which offline 178 CRLs actually have an advantage over online queries), resulting in scalability 179 and deployment problems. This lack of scalability is sever enough that 180 several vendors have resorted to removing replay protection from the protocol 181 (making it possible for an attacker to undetectably replay old responses) 182 because this is the only way to get OCSP to scale. 184 In many cases, a lightweight MAC (in other words CMS AuthenticatedData) is all 185 that's required to authenticate a response, and where alternative security 186 measures are used (for example IPsec or the use of a physically secure 187 network), no explicit authentication (in other words CMS Data) may be 188 necessary, allowing RTCS queries to proceed at network link/server turnaround 189 speed. When parties have a long-term relationship (examples being OCSP access 190 concentrators or in Identrus terminology transaction coordinators) and perform 191 large numbers of transactions, authenticating the transactions via MACs makes 192 more sense than signing each one. Similarly, when the producer and consumer 193 of the information are on opposite sides of the same server room, there is 194 little need for high-overhead signatures on each message. 196 A design goal of RTCS then is that, living up to its name, it must be able to 197 provide high-throughput, low-overhead realtime service to relying parties, via 198 the flexible selection of data formats provided by CMS. 200 2.6 Use in constrained environments 202 As an extension of the previous requirement, the protocol should be capable of 203 running in resource- or bandwidth-constrained environments. In its most 204 minimal implementation, RTCS has a small number of fixed-length fields, 205 allowing it to be used by dropping data into pre-generated CMS PDUs. The very 206 small message size and minimal processing requirements make it ideal for use 207 with mobile and remote devices, high-volume transaction systems, and in other 208 constrained environments. 210 2.7 Reliance on synchronised clocks 212 OCSP uses timestamps for all responses, assuming that the relying party and 213 responder somehow have perfectly synchronised clocks. This is rarely the 214 case, with systems having been encounted with clocks that are as much as 215 decades out of sync [Gutmann]. RTCS, almost by definition, does not rely on 216 synchronised clocks for its operation, although it can make use of them when 217 they are available. 219 3. RTCS 221 RTCS is designed to provide online, real-time certificate status information 222 using the CMS message format, in a manner that meets all of the design goals 223 given in section 2. 225 3.1 RTCS requests 227 An RTCS request consists of an indication of the type of reply required from 228 the responder and a list of certificates for which information is required: 230 RtcsRequest ::= CMS { RtcsRequests IDENTIFIED BY rtcsRequest } 232 rtcsRequest OBJECT IDENTIFIER { 1 3 6 1 4 1 3029 4 1 4 } 234 RtcsResponseType OBJECT IDENTIFIER ::= { 235 rtcsBasic { 1 3 6 1 4 1 3029 4 1 5 }, 236 rtcsExtended { 1 3 6 1 4 1 3029 4 1 6 }, 237 ... 238 } 240 RtcsRequests ::= SEQUENCE { 241 responseType RtcsResponseType DEFAULT rtcsBasic, 242 requests SEQUENCE OF RtcsRequestInfo, 243 attributes Attributes OPTIONAL 244 } 246 responseType is the type of response requested from the responder. If the 247 responder cannot provide the requested response type, if MUST return an 248 rtcsBasic response instead. 250 requests is the sequence of identifiers for the certificates being queried. 252 attributes is normally unnecessary, but is provided for use when the 253 encapsulating CMS type doesn't provide for the conveyance of attributes. If 254 the encapsulating CMS type supports the conveyance of attributes, they MUST 255 be included in the CMS encapsulation rather than in the RTCS request 256 attributes field. 258 As the ASN.1 above indicates, any of the standard CMS encapsulation types may 259 be used to contain the RTCS request, providing authentication and/or 260 confidentiality as required. 262 RtcsRequestInfo ::= SEQUENCE { 263 certHash OtherHash, 264 legacyID IssuerAndSerialNumber OPTIONAL 265 } 267 certHash is an SHA-1 hash of the certificate. Almost everything implements 268 this (variously as "fingerprint" or "thumbprint" or under some similar 269 name), the ID type is widely recognised, and interoperability/correctness 270 checking is trivial to achieve. The full definition of OtherHash is given 271 in [RFC3126], however as used here it SHOULD be regarded as a pure sha1Hash: 273 sha1Hash ::= OCTET STRING SIZE(20) 275 legacyID is provided when backwards-compatibility with CRL-based legacy 276 implementations or implementations that only support the traditional CMS 277 certificate identifier are required. The full definition is given in 278 [RFC3369]. This identifier is the standard certificate identifier for CMS 279 and S/MIME, and may be trivially generated from any X.509 certificate. This 280 identifier MUST be included when it is known that the responder is a legacy 281 implementation, and SHOULD be used when the client is unclear as to the 282 status of the responder. It MAY be omitted in resource-constrained 283 environments, or when the client knows that the responder is capable of 284 handling the certHash. See the security considerations for a note on this 285 identifier type. 287 3.1.1 Additional requirements 289 Since RTCS doesn't depend on synchronised clocks, implementations operating in 290 environments where replay attacks are a concern MUST use the randomNonce 291 extension [RFC2985] to ensure freshness of replies. For the avoidance of any 292 doubt, when no replay protection is required (for example when other security 293 measures such as link encryption/authentication or a physically secure link 294 are in place), no nonce is required. When replay protection is required and 295 the request or response is communicated using a CMS data type with no 296 provision for communicating attributes (for example CMS Data or CMS 297 EnvelopedData), the nonce MUST be communicated in the rtcsRequest attributes 298 field. If the request or response is communicated using a CMS data type that 299 supports the communication of attributes (for example CMS SignedData or CMS 300 AuthenticatedData), the nonce MUST be communicated as a CMS authenticated 301 attribute. RTCS implementations MUST support Data requests and SignedData 302 responses, SHOULD support SignedData requests, and MAY support other standard 303 CMS message types and combinations such as Data requests and responses or 304 EncrypteData requests and responses. 306 3.1.2 Zone transfers 308 Sometimes it may be desirable for a client to obtain all of the information 309 held by an RTCS responder, for example for mirroring/replication purposes. To 310 provide for RTCS zone transfers, a certHash of all zero bits is used to 311 indicate that it the responder should send information on all certificates 312 that it is authoritative for, and a certHash of all one bits is used to 313 indicate that the responder should send information on all certificates. 314 Responders MAY implemenent this facility by checking for these special 315 certHash values and responding appropriately. 317 Since zone transfers can consume significant resources, responders SHOULD 318 enforce some form of security controls on these requests, for example by 319 requiring them to be authenticated via CMS SignedData or AuthenticatedData, or 320 by only allowing them when the request is conveyed via a trusted/secure link. 322 3.1.3 Implementation notes and rationale 324 The certHash identifier meets the requirements in section 2.3 (use of a 325 widely-accepted, simple, universal identifier for certificates) and section 326 2 (ability to be used in a constrained environment). 328 The certificate hash is a universal identifier in that it doesn't care what 329 type or version of certificate is used, whether it's encoded in DER or BER or 330 XER, or whether the certificate even has a DN. It works with X.509 331 certificates (v1, v2, or v3) with or without extensions, X.509 attribute 332 certificates (v1 or v2), special-case certificates such as X9.68 domain 333 certificates, and any other certificate or certificate-like object that may 334 appear in the future. The hash does not require writing, testing, documenting 335 and maintaining the programming logic needed to handle DN complexity, and is 336 immune to the DN-based problems that affect OCSP. 338 The backup legacyID may be used with CRL-based legacy implementations, or in 339 situations where the certificate store is implemented as an LDAP directory 340 that identifies certificates by DN. This ensures full backwards compatibility 341 with CRL-based implementations, and an ability to function with LDAP 342 directories that isn't possible with OCSP since it destroys the DN by hashing 343 it. 345 Implementations are required to support at least the rtcsBasic response type, 346 falling back to this type if the requested type can't be provided. This 347 ensures that at least some form of response is always provided, even if it 348 consists only of an indication that no definitive status is available. 350 A resource- or bandwidth-constrained environment may use a pre-generated RTCS 351 query and copy the certHash directly into a fixed location in the query. This 352 makes RTCS amenable for use in crypto tokens or mobile devices or high-volume 353 transaction systems that don't have the resources to handle a full 354 implementation and that merely populate a pre-generated query with a fresh 355 nonce and 20-byte certHash. 357 The full definition of OtherHash, from [RFC3126], is: 359 OtherHash ::= CHOICE { 360 sha1Hash OCTET STRING SIZE(20), 361 otherHash OtherHashAlgAndValue 362 } 364 OtherHashAlgAndValue ::= SEQUENCE { 365 hashAlgorithm AlgorithmIdentifier, 366 hashValue OCTET STRING 367 } 369 The intent here is that if a weakness is found in SHA-1, an alternative hash 370 algorithm may be substituted in its place. Since every Internet security 371 protocol ever created would require replacing if SHA-1 was broken this is 372 probably a lesser concern, but an alternative is provided here anyway. In 373 standard usage the above simplies to a straight SHA-1 hash. 375 A pure boolean response (corresponding to a present/absent check in the 376 authenticated dictionary) provides for considerable efficiency improvments on 377 the server, since such a check can be implemented using a mechanism such as a 378 (suitably tuned) Bloom filter that takes advantage of the fact that the query 379 material is already pre-hashed by the client. Clients should submit basic 380 queries (which allow for a simple boolean response) if possible, rather than 381 asking for a full response every time simply because it's available. 382 Conversely, servers may perform a simple boolean lookup initially on the 383 assumption that the majority of certificates being queried will be valid, and 384 only fall back to a more time-consuming full lookup if the initial boolean 385 lookup returns a response of 'false'. 387 RTCS zone transfers work in the same way as, and have the same implications 388 as, DNS zone transfers. Any standard reference on DNS operations or DNS 389 security will contain further details on this issue. A typical configuration 390 would contain an RTCS primary and secondary responder, just as with DNS 391 servers, with synchronisation being performed via RTCS zone transfers. An 392 alternative strategy, used by some DNS servers, is one in which one server is 393 used for updates and one or more further servers, updated via zone transfers, 394 are used to respond to queries. Again, standard DNS practice provides 395 guidance on building a high-availability, fault-tolerant system on this basis. 396 In fact a scheme similar to RTCS that uses DNS instead of its own specific 397 protocol has already been in general use in Europe as part of the X-Road 398 project. 400 The means of requesting an RTCS zone transfer has been chosen so that a client 401 or server implemenetation can choose not to provide for zone transfers without 402 any special-case handling for requests or responses. A client requesting a 403 zone transfer from a responder that doesn't support them will receive a no- 404 information response as it would when querying a nonexistant certificate. 406 3.2 RTCS response 408 RTCS provides for two response types, a basic response when only a simple 409 yes/no status is required, and a full response when extended information is 410 required. 412 RTCSRESPONSE ::= TYPE-IDENTIFIER 414 RtcsResponse ::= CMS { RTCSRESPONSE.&Type({ RtcsResponseTypes }{ @.type-id }) } 416 RtcsResponseTypes RTCSRESPONSE ::= { 417 rtcsResponseBasic | rtcsResponseExtended, 418 ... 419 } 421 rtcsResponseBasic RTCSRESPONSE ::= { 422 SYNTAX RtcsResponsesBasic ID { rtcsBasic } 423 } 425 rtcsResponseExtended RTCSRESPONSE ::= { 426 SYNTAX RtcsResponsesExtended ID { rtcsExtended } 427 } 429 As the ASN.1 above indicates, any of the standard CMS encapsulation types may 430 be used to contain the RTCS response, providing authentication and/or 431 confidentiality as required. 433 3.2.1 RTCS basic response 435 This is a straightforward yes/no response type: 437 RtcsResponsesBasic ::= SEQUENCE OF RtcsResponseBasic 439 RtcsResponseBasic ::= SEQUENCE { 440 certHash OtherHash, 441 status BOOLEAN 442 } 444 A returned value 'true' indicates that the certificate is valid right now. 445 This is a clear, unambiguous response that is useful for relying parties who, 446 having a certificate at hand, simply want to know whether they can safely use 447 it or not, and no more. A returned value 'false' indicates that the 448 certificate is not valid right now, either because it has been explicitly 449 rendered invalid in some manner (for example by being revoked) or because no 450 definitive status information is available. Relying parties who require 451 further information SHOULD use the extended response type defined in section 452 3.2.2. 454 3.2.2 RTCS extended response 456 This is an extended response type returning more information than the basic 457 RTCS response: 459 RtcsResponsesExtended ::= SEQUENCE OF RtcsResponseExtended 461 RESPONSEINFO ::= CLASS { 462 &status CertStatus UNIQUE, 463 &StatusInfo OPTIONAL 464 } WITH SYNTAX { &status [WITH DETAILS IN &StatusInfo] } 466 RtcsResponseExtended ::= SEQUENCE { 467 certHash OtherHash, 468 status RESPONSEINFO.&status({ CertStatus }), 469 statusInfo RESPONSEINFO.&StatusInfo({ CertStatus }{ @status }), 470 attributes [0] Attributes OPTIONAL 471 } 473 ResponseTypes RESPONSEINFO ::= { 474 { statusOK } | 475 { statusNotOK WITH DETAILS IN InvalidityInfo } | 476 { statusNonAuthoritative 477 WITH DETAILS IN NonAuthoritativeInfo } | 478 { statusNoInformation }, 479 ... 480 } 482 CertStatus ::= ENUMERATED { 483 statusOK (0), 484 statusNotOK (1), 485 statusNonAuthoritative (2), 486 statusNoInformation (3), 487 ... 488 } 490 In order to provide time information without requiring synchronised clocks 491 (see section 2.7), RTCS uses a relative time value that provides the time as 492 seen by the responder alongside the time at which an event occurred. This 493 eliminates the need for the responder and relying party to have precisely 494 synchronised clocks. The relying party may use the absolute time if they have 495 a mechanism for precise clock synchronisation with the responder, or the 496 difference between the two times to determine how far in the past relative to 497 its own clock the event took place. 499 RelativeTimeInfo ::= SEQUENCE { 500 responderTime GeneralizedTime, 501 eventTime GeneralizedTime 502 } 504 3.2.2.1 Extended status OK 506 This status value is identical to the basic response equivalent and indicates 507 that the certificate is valid right now. 509 3.2.2.2 Extended status not-OK 511 If the certificate has been revoked or rendered invalid in some form, the 512 responder will return a "not-OK" response: 514 InvalidityInfo ::= SEQUENCE { 515 invalidityTime RelativeTimeInfo OPTIONAL, 516 invalidityReason CRLReason OPTIONAL 517 } 519 invalidityTime indicates the time at which the revocation or invalidation 520 took place, if available. 522 invalidityReason provides the reason why the certificate was revoked or 523 rendered invalid, if available. 525 3.2.2.3 Extended status non-authoritative response 527 This response type may appear when the response is non-authoritative. This 528 situation can occur when the responder being queried obtains information by 529 chaining to another, authoritative responder (an origin server in HTTP 530 terminology) which is temporarily unavailable. Authoritative responders MUST 531 NOT return the statusNonAuthoritative status. Non-authoritative responders 532 may either indicate that no authoritative response is available by omitting 533 the NonAuthoritativeInfo, or provide a non-authoritative response (for example 534 from cached data) in NonAuthoritativeInfo: 536 NonAuthCertStatus ::= CertStatus ( EXCEPT statusNonAuthoritative ) 538 NonAuthoritativeInfo ::= SEQUENCE { 539 lastAuthTime RelativeTime, 540 status RESPONSEINFO.&status({ NonAuthCertStatus }), 541 statusInfo RESPONSEINFO.&StatusInfo({ NonAuthCertStatus }{ @status }) 542 } 544 lastAuthTime indicates the time at which the last authoritative response was 545 obtained. 547 The other fields are as defined in section 3.2.2. 549 3.2.2.4 Extended status no information available 551 This status value indicates that the queried object doesn't exist, being 552 neither a valid, nor an invalid, certificate (it could for example be a forged 553 certificate from a third party, or an Excel spreadsheet). Note that this 554 differs from the OCSP "unknown" response, which could mean all manner of 555 things (see section 2.4). 557 3.2.3 Implementation notes and rationale 559 The response returned is not intended to be an intrusion into DPD/DPV 560 territory, but simply represents the only response an authenticated dictionary 561 can return. Just as a CRL can only say with certainty "revoked", so an 562 authenticated dictionary can only say with certainty "present" (and 563 conversely, "not present"). 565 The returned status value meets the requirements in section 2.4 (use of an 566 unambiguous status value) and section 2.7 (no reliance on synchronised 567 clocks). The basic response meets the requirements in section 2.6 (use in 568 resource-constrained environments) as well as being the response type of 569 choice in environments where the relying party only cares about a yes/no 570 indicator. This follows the credit card authorisation model, where the 571 merchant only really cares about accepted/declined, and not a 15-page 572 financial statement about why the transaction wasn't accepted. This usage 573 model is exemplified by one commercial S/MIME implementation that boiled the 574 entire certificate checking process down to a single value 575 bCanUseTheDamnThing, because that was the only information that mattered to 576 the user. The response format meets the requirements in section 2.5 577 (lightweight/realtime operation) since it allows heavyweight signatures or 578 lightweight MACs to be used as required. 580 For relying parties requiring full information, the extended response provides 581 further details. 583 A resource-constrained environment may request a basic response and copy the 584 status directly from a fixed location in the response. This makes RTCS 585 amenable for use in crypto tokens or mobile devices that don't have the 586 resources to handle a full implementation. Note however that clients should 587 not assume that response information occurs in the same order as request 588 information when more than one certificate is being queried in an RTCS 589 request. That is, if request information for a certificate is present at 590 position n in the RTCS request then it is not safe to assume that the returned 591 response will similarly contain the certificate status at position n. 592 Instead, clients should use the certificate identifier to match response 593 information to request information. 595 Responders can be operated in one of two modes. In the most common mode, the 596 responder is authoritative and returns responses directly from the certificate 597 store or a shapshot of the certificate store. In the less common mode, the 598 responder acts as an access concentrator/transaction coordinator/proxy for 599 other responders. The following discussion of non-authoritative responses and 600 responders borrows from DNS concepts and terminology, which faces a similar 601 situation when handling DNS queries. 603 When a responder is non-authoritative, it may not be able to return a response 604 to a query directly from the authoritative source, or for performance reasons 605 may return a cached response, just as with DNS and HTTP servers. In this case 606 the responder can return the last authoritative response, along with an 607 indication as to how low ago the response was authoritative. The relying 608 party can then make a decision, based on the age of the cached response and 609 the value of the data involved, to rely on the cached information or to wait 610 for a fresh, authoritative response to become available. 612 Note that the use of the term "authoritative" differs slightly from its use in 613 DNS. In DNS, cacheing for load-distribution purposes is very common, and 614 mechanisms to handle it are built ito the DNS, whereas with RTCS it would only 615 be used when there isn't a requirement for a hard real-time response. 616 However, RTCS can return an authoritative response (via an access 617 concentrator/transaction coordinator/proxy) without the responder which is 618 being queried itself being authoritative. In HTTP terminology, the source of 619 the authoritative response is an origin server, with caches acting as 620 intermediaries to improve performance. In this case the response is regarded 621 as being authoritative, since it is being forwarded from an authoritative 622 source/origin server. Only a cached response is non-authoritative. This 623 differs from DNS, where the authority of an answer and the authority of a DNS 624 server are synonymous. Further discussion of this style of cacheing model may 625 be found in section 13 of [RFC2616]. This document is recommended reading for 626 anyone considering the use of response cacheing for RTCS performance 627 enhancement purposes. 629 The HTTP protocol allows the client to override cacheing behaviour on the 630 server through the "Cache-control: no-cache" directive, which indicates that 631 the server must provide an authoritative response. In RTCS this is controlled 632 by the server, with an explicit indication in the response as to whether it is 633 authoritative or not. In other words, the server always provides some form of 634 response, and leaves it to the client to decide whether to utilise it or not. 635 This is based on the view that the client is in a far better position to judge 636 this than the server, since the client/relying party is the one that runs the 637 risk if a decision arising from the validity of the certificate is wrong and 638 not the responder. 640 [Note: Should add a max-age extension to requests to allow a forced end-to-end 641 reload]. 643 3.2.4 High-speed/High-volume Responder Design 645 The simple yes/no response option may be used in applications where a high- 646 speed response is required or a high volume of transactions is expected. 647 Observe that the certHash identifier consitutes the application of a high- 648 quality hash function, which should give a perfectly flat distribution of hash 649 values, with all the work being performed by the client. The responder merely 650 has to select n bits of the hash value and perform a lookup in a table of 2^n 651 bits (with appropriate handling of hash chaining/overflows, this is a standard 652 problem from the literature). This means of implementing a certificate status 653 responder is probably the fastest certificate status query mechanism possible. 655 The use of the CMS format allows further optimisation for high-speed 656 operation, either by taking advantage of hardware acceleration or by using 657 low-overhead MACs instead of high-overhead signatures. PKCS #11 [PKCS11] 658 directly supports the CMS message format, allowing responses to be generated 659 directly by the crypto hardware. Alternatively, CMS supports the use of MACs 660 rather than signatures, allowing responses to be generated with minimal 661 overhead in resource-constrained or high-volume applications. 663 The use of pre-shared MAC keys presupposes a long-term relationship between an 664 initiator and the RTCS responder, for example where an online transaction 665 processing facility is continuously querying a back-end for certificate status 666 information. However, CMS also allows MAC keys to be established on the fly 667 via standard CMS key exchange mechanisms, which may then be cached by the 668 initiator and RTCS responder for future use. In this manner the initial query 669 necessitates a (relatively) high-overhead private-key operation to unwrap the 670 MAC key (the equivalent of a single signed OCSP response), while subsequent 671 queries can proceed at full speed using MAC'ed messages. 673 To reduce the load on the server, the MAC key exchange may be initiated by the 674 server rather than the client. In this way the server performs the 675 lightweight public-key wrap while the client has to perform the more 676 heavyweight private-key unwrap. 678 Further speed optimisations may be obtained by observing that due to the 679 application of the ASN.1 distinguished encoding rules (DER), standard queries 680 and responses have a fixed format, so they may be pre-encoded before 681 transmission and applied as a fixed-format template, and don't need to be 682 decoded on reception because all of the fields are at fixed locations. This 683 means that a high-speed responder can pull the hash value directly from a 684 fixed location in incoming queries, perform the lookup, drop the result into 685 another fixed location in a response template, and enqueue it for transmission 686 back to the initiator. 688 Various network efficiency considerations need to be taken into account when 689 implementing this certificate distribution mechanism. For example, a 690 simplistic implementation that performs two writes (the HTTP header and the 691 certificate written seperately) followed by a read will interact badly with 692 TCP delayed-ACK and slow-start. This occurs because the TCP MSS is typically 693 1460 bytes on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers 694 are ~200-300 bytes, far less than the MSS. When an HTTP message is first 695 sent, the TCP congestion window begins at one segment, with the TCP slow-start 696 then doubling its size for each ACK. Sending the headers separately will send 697 one short segment and a second MSS-size segment, whereupon the TCP stack will 698 wait for the responder's ACK before continuing. The responder gets both 699 segments, then delays its ACK for 200ms in the hopes of piggybacking it on 700 responder data, which is never sent since it's still waiting for the rest of 701 the HTTP body from the initiator. This behaviour results in a 200ms (+ 702 assorted RTT) delay in each message sent. 704 There are various other considerations that need to be taken into account in 705 order to provide maximum efficiency. These are covered in depth elsewhere 706 [Spero] [Heidemann] [Nielsen]. In addition, modifications to TCP's behaviour 707 such as the use of 4K initial windows [RFC3390] (designed to reduce small HTTP 708 transfer times to a single RTT) should also ameliorate some of these issues. 710 A rule of thumb for optimal performance is to combine the HTTP header and data 711 payload into a single write (any reasonable HTTP implementation will do this 712 anyway, thanks to the considerable body of experience that exists for HTTP 713 server performance tuning), and to keep the HTTP headers to a minimum to try 714 and fit data within the TCP MSS. Since this protocol doesn't involve a web 715 browser, there's no need to include the usual headers covering browser 716 versions and languages and so on; a minimal set of content-type/encoding and 717 host and session control information will suffice. 719 For even better network performance in the presence of large numbers of point 720 queries (single requests rather than an ongoing sequence of requests), RTCS 721 should be run directly over UDP (without any HTTP encapsulation), eliminating 722 the cost of the TCP connection setup and additional protocol overhead. The 723 fixed-format, compact RTCS queries and responses make them ideal for 724 transmission over UDP rather than TCP. Further details on scaling this form 725 of query/response infrastructure may be found in any work that discusses DNS 726 query handling. 728 4. Security considerations 730 The legacyID is based on the assumption that DNs in certificates are unique. 731 Although all of X.500 is built upon this assumption, it has been claimed that 732 this may not always be the case. If this is a concern, a DN-based identifier 733 is insufficient to uniquely identify a certificate and the certHash 734 alternative should be used. RTCS always transmits the certHash, so this can 735 always be relied upon to uniquely identify the certificate even in the 736 presence of duplicate, missing, or arbitrarily broken, DNs. 738 Appendix A: MIME Wrapping 740 When RTCS is used in a MIME environment, the S/MIME v3 MIME wrapping rules 741 apply [RFC2633]. The optional smime-type parameter MUST have the value "rtcs- 742 request" for RTCS requests with a file name extension "rrq", and "rtcs- 743 response" for RTCS responses with a file name extension "rrs". All other 744 details are specified in [RFC2633]. 746 Appendix B: Use of RTCS with CMS 748 This document has described a general-purpose CMS-compatible means of 749 communicating certificate status information. When used in conjunction with 750 other CMS data, it can be inserted as an authenticated or unauthenticated 751 attribute if the CMS data type supports this. The object identifier used to 752 identify RTCS responses communicated as CMS attributes is: 754 rtcsData { 1 3 6 1 4 1 3029 3 1 4 } 756 For example a sender may insert an RTCS response as an authenticated attribute 757 in SignedData to prove that its certificate was valid at the time of signing. 758 An S/MIME gateway or forwarder could insert an RTCS response covering the 759 certificates in the messages it processes as an unauthenticated attribute, 760 allowing clients behind the gateway to determine the validity of the 761 certificates used to sign messages they process without having to perform an 762 RTCS query themselves. This allows RTCS to be used with clients with limited 763 resources, or in situations where only the messaging gateway (but not clients 764 located behind it) have general network access for querying RTCS responders. 765 Note though that in this case the eventual consumer of the information and the 766 RTCS responder require synchronised clocks, since the information is no longer 767 being communicated via an interactive, real-time exchange. 769 Appendix C: Sample RTCS Messages 771 <<>> 773 References (Normative) 775 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 776 Scott Bradner, RFC 2119, March 1997. 778 [RFC2633] "S/MIME Version 3 Message Specification", RFC 2633, 779 Blake Ramsdell, June 1999. 781 [RFC2985] "PKCS #9: Selected Object Classes and Attribute Types, 782 Version 2.0", RFC 2985, Magnus Nystrom and Burt Kaliski, 783 November 2000. 785 [RFC3126] "Electronic Signature Formats for long term electronic 786 signatures", Harri Rasilainen, Denis Pinkas, John Ross, 787 Nick Pope, September 2001. 789 [RFC3369] "Cryptographic Message Syntax (CMS)", Russ Housley, 790 August 2002. 792 [RFC3379] "Delegated Path Validation and Delegated Path Discovery 793 Protocol Requirements", Denis Pinkas and Russ Housley, 794 September 2002. 796 [X.680] "Information Technology - Abstract Syntax Notation One", 797 ITU-T Recommendation X.680 (2002) / ISO/IEC 8824-1:2002, 798 2002. 800 References (Informative) 802 [Gutmann] "Lessons Learned in Implementing and Deploying Crypto 803 Software", Peter Gutmann, Proceedings of the 2002 Usenix 804 Security Symposium, August 2002. 806 [Heidemann] "Performance Interactions Between P-HTTP and TCP 807 Implementations", J.Heidemann, ACM Computer Communications 808 Review, April 1997. 810 [Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG", 811 H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie, 812 and C.Lilley, 24 June 1997, 813 http://www.w3.org/Protocols/HTTP/1.0/Performance/Pipeline.html. 815 [PKCS11] "PKCS #11 Cryptographic Token Interface Standard, v2.20", 816 RSA Laboratories, 2003. 818 [RFC2616] "Hypertext Transfer Protocol, HTTP/1.1", Roy Fielding, Jim 819 Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul 820 Leach, and Tim Berners-Lee, June 1999. 822 [RFC3390] "Increasing TCP's Initial Window", RFC 3390, M.Allman, S.Floyd, 823 and C.Partridge, October 2002. 825 [Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994, 826 http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html. 828 Acknowledgements 830 The author would like to thank Denis Pinkas for providing the motivation to 831 finish this draft, members of the RTCS cabal and users of the cryptlib toolkit 832 for feedback on requirements and comments on issues such as use in constrained 833 environments and handling of superseded certificates, Phil Griffin for ASN.1 834 technical advice, and an anonymous PKI architect for the observation that 835 "Learning in 80 ms that the cert was good as of a week ago and to not hope for 836 fresher information for another week seems of limited, if any, utility to us 837 or our customers". 839 Author Address 841 Peter Gutmann 842 University of Auckland 843 Private Bag 92019 844 Auckland, New Zealand 846 Email: pgut001@cs.auckland.ac.nz 848 Full Copyright Statement 850 Copyright (C) The Internet Society (2003). All Rights Reserved. 852 This document and translations of it may be copied and furnished to others, 853 and derivative works that comment on or otherwise explain it or assist in its 854 implementation may be prepared, copied, published and distributed, in whole or 855 in part, without restriction of any kind, provided that the above copyright 856 notice and this paragraph are included on all such copies and derivative 857 works. However, this document itself may not be modified in any way, such as 858 by removing the copyright notice or references to the Internet Society or 859 other Internet organizations, except as needed for the purpose of developing 860 Internet standards in which case the procedures for copyrights defined in the 861 Internet Standards process must be followed, or as required to translate it 862 into languages other than English. 864 The limited permissions granted above are perpetual and will not be revoked by 865 the Internet Society or its successors or assigns. 867 This document and the information contained herein is provided on an "AS IS" 868 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 869 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 870 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 871 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 872 PURPOSE.