idnits 2.17.00 (12 Aug 2021) /tmp/idnits55707/draft-gutmann-ocsp-rtcs-00.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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 624 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 231 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC3379]), 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 (January 2003) is 7066 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) == Missing Reference: 'RFC2119' is mentioned on line 76, but not defined -- Looks like a reference, but probably isn't: '2' on line 205 -- Looks like a reference, but probably isn't: '0' on line 423 == Unused Reference: 'RFC 2119' is defined on line 537, but no explicit reference was found in the text ** 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 Summary: 10 errors (**), 0 flaws (~~), 7 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-ocsp-rtcs-00.txt University of Auckland 3 Expires July 2003 January 2003 5 Real-time Certificate Status Facility for OCSP - (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 When the OCSP protocol was defined, the design was based on full compatibility 34 with CRL-based mechanisms. This requires the use of a complex means of 35 certificate identification that has resulted in interoperability problems 36 among implementations, a design unsuited for high-throughput, real-time 37 operation, the inability to provide an unambiguous certificate status response 38 (the only thing that a CRL can say with certainty is "revoked"), and an online 39 responder tied to an offline mechanism (some CAs issue CRLs only once or twice 40 a day, even though they have an online, real- time certificate store 41 available). A more practical problem is that it makes it impossible to 42 implement an OCSP responder not based on CRLs, for example one that consults a 43 certificate database or in-memory hash table to determine the presence or 44 absence of a valid certificate. 46 Fortunately, the authors of the OCSP RFC foresaw this situation by allowing a 47 client to specify, and a responder to return, more than one type of response. 48 Just as the original OCSP responses were designed for completely CRL- 49 compatible operation, this document specifies a response type that is designed 50 for real-time status operation, providing a response not from a stored CRL 51 using CRL-only mechanisms but directly from a live certificate store or in- 52 memory hash table. This allows the responder to provide extended information 53 not possible with CRLs, combined a high level of performance not possible with 54 the original OCSP design. 56 In abstract terms, the responder is providing an implementation of an 57 authenticated dictionary D that responds to membership queries from relying 58 parties. A conventional OCSP responder answers the question "Is x excluded 59 from D?", while an OCSP responder with RTCS capability answers the question 60 "Is x present in D?". 62 When returning a response, the responder is merely indicating that the queried 63 certificate is currently present in its set of valid certificates. It is 64 purely an authenticated dictionary service and does not verify the certificate 65 in any way. Relying parties requiring external verification services should 66 use the PKIX standard mechanisms for this [RFC 3379] and not RTCS. 67 Specifically, RTCS does not provide, and should not be assumed to provide, any 68 of the functionality of DPD/DPV. It is purely a mechanism for running a high- 69 performance OCSP responder directly from a CA certificate store/in-memory 70 table. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 73 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 74 uppercase, as shown) are to be interpreted as described in [RFC2119] ,except 75 when they appear in ASN.1 constructs, in which case they follow [X.680] 77 2. Problem analysis 79 This section examines the problems that need to be solved by the protocol, and 80 provides a rationale for design decisions. The next section defines the 81 protocol based on the design decisions. 83 2.1 Certificate identification 85 OCSP defines a complex certificate identifier that takes portions of the 86 certificate, hashes some (making reference to the original value impossible), 87 doesn't hash others, and even requires a hash of data from other certificates 88 to be included as part of the identifier, making it impossible to query the 89 status of a single, standalone certificate. Real-world experience has shown 90 that implementors have considerable difficulty with this identifier, leading 91 to interoperability problems among implementations. 93 A major design goal of RTCS then is to provide a simple, widely-accepted, 94 universally-applicable identifier for all certificates, regardless of their 95 schema or encoding. For compatibility with legacy implementations, it also 96 provides a CRL-compatible identifier, although there are some caveats attached 97 to its use (see section 3.1). 99 2.2 Returned status value 101 Because of its CRL-based origins, OCSP can only return a negative response. 102 For example, when fed a freshly-issued certificate and asked "Is this a valid 103 certificate", it can't say "Yes" (a CRL can only answer "revoked"), and when 104 fed an Excel spreadsheet it can't say "No" (the spreadsheet won't be present 105 in any CRL). This problem interacts badly with the one in section 2.1 in that 106 an unknown response could mean anything from "I couldn't find a CRL for this 107 certificate" to "I don't know the status of this certificate" to "This may 108 well be a valid certificate but your software and mine disagree over how to 109 generate the identifier", and there is no way to determine what the actual 110 problem is. 112 The second major design goal of RTCS then is to provide a clear, unambiguous 113 response to any query, either "This certificate is definitely valid right 114 now", "This certificate is definitely not valid right now", or "The object you 115 have queried doesn't exist" (standard OCSP can't do any of these). 117 2.3 Lightweight/realtime operation 119 OCSP requires that every response from a responder be authenticated with a 120 signature, whether this is appropriate or not. In cases where high 121 transaction volumes need to be handled, the overhead of having to sign each 122 transaction can be prohibitive (this is one of the few areas in which offline 123 CRLs actually have an advantage over online queries), resulting in scalability 124 and deployment problems. In many cases, a lightweight MAC is all that's 125 required to authenticate a response, and where alternative security measures 126 are used (for example IPsec or the use of the physically secure network), no 127 explicit authentication may be necessary, allowing RTCS queries to proceed at 128 network link/server turnaround speed. For example when parties have a long- 129 term relationship (examples being OCSP access concentrators or in Identrus 130 terminology transaction coordinators) and perform large numbers of 131 transactions, authenticating the transactions via MACs makes more sense than 132 signing each one. Similarly, when the producer and consumer of the 133 information are on opposite sides of the same server room, there is little 134 need for high-overhead signatures on each message. 136 A third design goal of RTCS then is that, living up to its name, it must be 137 able to provide high-throughput, low-overhead realtime service to relying 138 parties. 140 2.4 Use in constrained environments 142 As an extension of the previous requirement, the protocol should be capable of 143 running in resource- or bandwidth- constrained environments. In its most 144 minimal implementation, RTCS has a small number of fixed-length fields, 145 allowing it to be used by dropping data into pre-generated PDUs. The very 146 small message size and minimal processing requirements make it ideal for use 147 with mobile and remote devices, high-volume transaction systems, and in other 148 constrained environments. 150 2.5 Use of standard/flexible data formats 152 The format used for OCSP responses is an incomplete reinvention of the 153 standard CMS format that lacks a number of CMS features, leading to various 154 implementation/deployment difficulties. For example, some responders need to 155 provide confidentiality protection for their responses, since returning an 156 indication that a certificate has been revoked may be interpreted as a 157 statement about the veracity of the organisation that owns the certificate, 158 leading to potential liability concerns (the same problem is faced by some 159 CAs, who have to password-protect or encrypt their CRLs). This is trivial to 160 implement using the standard CMS format, but impossible with the OCSP 161 reinvention of CMS, requiring the use of ad-hoc/proprietary extensions. 162 Responders that operate in resource-constrained environments (see section 2.4) 163 or that require high-throughput operation (see section 2.3) may choose to 164 authenticate their responses with a low-overhead MAC rather than a high- 165 overhead signature. Again, this is impossible with the OCSP format but 166 trivial with CMS. 168 Finally, CMS is the standard format for signed/encrypted/MAC'ed data. Using 169 this format rather than an incompatible reinvention of the format allows for 170 simple implementations based on existing code. In the case of the OCSP 171 specification, more than half the ASN.1 is dedicated to reinventing the CMS 172 message format; omitting this unnecessary step considerably simplifies the 173 specification and the task of implementation. 175 2.6 Reliance on synchronised clocks 177 OCSP uses timestamps for all responses, assuming that the relying party and 178 responder somehow have perfectly synchronised clocks. This is almost never 179 the case, with systems having been encounted with clocks that are as much as 180 decades out of sync [Gutmann]. RTCS, almost by definition, does not rely on 181 synchronised clocks for its operation. 183 3. RTCS 185 RTCS is designed to provide online, real-time certificate status information 186 by direct reference to a certificate store, in a manner that meets all of the 187 design goals given in section 2. 189 3.1 RTCS requests 191 RTCS makes use of the OCSP AcceptableResponses extension to specify the 192 response types that it will accept. There are two response types, a simple 193 basic status value suitable for use when only a yes/no response is required or 194 in resource-constrained environments, and an extended response type suitable 195 for use when more information is required. 197 The response types are identified by: 199 rtcsBasic OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 } 200 rtcsExtended OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 3 } 202 In order to identify the certificate, RTCS extends the existing OCSP 203 identifiers to use the following new identifier type: 205 RtcsIdentifier ::= [2] SEQUENCE { 206 certHash OtherHash, 207 legacyID IssuerAndSerialNumber OPTIONAL 208 } 210 certHash is an SHA-1 hash of the certificate. Almost everything implements 211 this (variously as "fingerprint" or "thumbprint" or under some similar 212 name), the ID type is widely recognised, and interoperability/correctness 213 checking is trivial to achieve. The full definition of OtherHash is given 214 in [RFC 3126], however as used here it SHOULD be regarded as a pure 215 sha1Hash: 217 sha1Hash ::= OCTET STRING SIZE(20) 219 legacyID is provided when backwards-compatibility with CRL-based legacy 220 implementations are required. The full definition is given in [RFC 3369]. 221 This identifier is widely used in CMS and S/MIME, and may be trivially 222 generated from any X.509 certificate. This identifier MUST be included 223 when it is known that the responder is a legacy implementation, and SHOULD 224 be used when the client is unclear as to the status of the responder. It 225 MAY be omitted in resource-constrained environments, or when the client 226 knows that the responder is capable of handling the certHash. See the 227 security considerations for a note on this identifier type. 229 Note that the tagging of the identifier is used to ensure non-interference 230 with existing OCSP identifiers. 232 3.1.1 Additional requirements 234 Since RTCS doesn't depend on synchronised clocks, implementations MUST use the 235 OCSP Nonce extension to ensure freshness of replies. 237 3.1.2 Implementation notes and rationale 239 The certHash identifier meets the requirements in section 2.1 (use of a 240 widely-accepted, simple, universal identifier for certificates) and section 241 2. (ability to be used in a constrained environment). 243 The certificate hash is a universal identifier in that it doesn't care what 244 type or version of certificate is used, whether it's encoded in DER or BER or 245 XER, or whether the certificate even has a DN. It works with X.509 246 certificates (v1, v2, or v3) with or without extensions, X.509 attribute 247 certificates (v1 or v2), special-case certificates such as X9.68 domain 248 certificates, and any other certificate or certificate-like object that may 249 appear in the future. The hash does not require writing, testing, documenting 250 and maintaining the programming logic needed to handle DN complexity, and is 251 immune to the DN-based problems that affect OCSP. 253 The backup legacyID may be used with CRL-based legacy implementations, or in 254 situations where the certificate store is implemented as an LDAP directory 255 that identifies certificates by DN. This ensures full backwards compatibility 256 with CRL-based implementations. 258 A resource- or bandwidth-constrained environment may use a pre-generated OCSP 259 query and copy the certHash directly into a fixed location in the query. This 260 makes RTCS amenable for use in crypto tokens or mobile devices or high-volume 261 transaction systems that don't have the resources to handle a full OCSP 262 implementation and that merely populate a pre-generated query with a fresh 263 nonce and 20-byte certHash. 265 The full definition of OtherHash, from [RFC 3126], is: 267 OtherHash ::= CHOICE { 268 sha1Hash OCTET STRING SIZE(20), 269 otherHash OtherHashAlgAndValue 270 } 272 OtherHashAlgAndValue ::= SEQUENCE { 273 hashAlgorithm AlgorithmIdentifier, 274 hashValue OCTET STRING 275 } 277 The intent here is that if a weakness is found in SHA-1, an alternative hash 278 algorithm may be substituted in its place. Since every Internet security 279 protocol ever created would require replacing if SHA-1 was broken, this is 280 probably a lesser concern, but an alternative is provided here anyway. In 281 standard usage the above simplies to a straight SHA-1 hash. 283 [Editorial note: Some users who have implemented ad-hoc confidentiality 284 protection mechanisms are using key IDs to identify keys for responses. This 285 can probably be kludged into the OCSP requestorName GeneralName in some way, 286 but it may be better to define a new request extension containing a standard 287 CMS identifier] 289 3.2 RTCS response 291 RTCS defines two response types, a basic response when only a simple yes/no 292 status is required, and a full response when extended information is required. 294 [Editorial note: This section originally contained an attempt to render the 295 original OCSP content in modern ASN.1 while adding the ability to use more 296 lightweight protection types such as MACs to allow realtime operation and to 297 allow confidentiality protection of responses, but it just got worse and 298 worse trying to capture the semantics, until it became easier to replace the 299 whole with CMS, which fixes everything in one fell swoop, as well as 300 providing standard, well-defined facilities for a variety of things tacked on 301 in OCSP. This also provides additional benefits which to date have had to be 302 added by vendors through proprietary/ad-hoc extensions, see section 2.5]. 304 RTCSRESPONSE ::= TYPE-IDENTIFIER 306 RtcsResponseBytes ::= SEQUENCE { 307 type RTCSRESPONSE.&id({ RtcsResponseTypes }), 308 response OCTET STRING (CONTAINING RtcsResponse) 309 } 311 RtcsResponse ::= CMS { RTCSRESPONSE.&Type({ RtcsResponseTypes }{ @.type-id }) } 313 RtcsResponseTypes RTCSRESPONSE ::= { 314 rtscResponseBasic | rtscResponseExtended, 315 ... 316 } 318 rtcsResponseBasic RTSCRESPONSE ::= { 319 SYNTAX RtcsResponsesBasic ID { rtcsBasic } 320 } 322 rtcsResponseExtended RTSCRESPONSE ::= { 323 SYNTAX RtcsResponsesExtended ID { rtcsExtended } 324 } 326 3.2.1 RTCS basic response 328 This is a straightforward yes/no response type: 330 RtcsResponsesBasic ::= SEQUENCE OF RtcsResponseBasic 332 RtcsResponseBasic ::= SEQUENCE { 333 certHash OtherHash, 334 status BOOLEAN, 335 } 337 A returned value 'true' indicates that the certificate is valid right now. A 338 returned value 'false' indicates that the certificate is not valid right now. 339 This is a clear, unambiguous response that is useful for relying parties who, 340 having a certificate at hand, simply want to know whether they can safely use 341 it or not, and no more. Relying parties who require further information 342 SHOULD use the extended response in section 3.2.2. 344 3.2.2 RTCS extended response 346 This is an extended response type returning more information than the basic 347 RTCS response: 349 RtcsResponsesExtended ::= SEQUENCE OF RtcsResponseExtended 351 RESPONSEINFO ::= CLASS { 352 &status CertStatus UNIQUE, 353 &StatusInfo OPTIONAL 354 } WITH SYNTAX { &status [WITH DETAILS IN &StatusInfo] } 356 RtcsResponseExtended ::= SEQUENCE { 357 certHash OtherHash, 358 status RESPONSEINFO.&status({ CertStatus }), 359 statusInfo RESPONSEINFO.&StatusInfo({ CertStatus }{ @status }), 360 } 362 ResponseTypes RESPONSEINFO ::= { 363 { statusOK } | 364 { statusRevoked WITH DETAILS IN RevocationInfo } | 365 { statusSuperseded WITH DETAILS IN SupersededInfo } | 366 { statusUnknown }, 367 ... 368 } 370 CertStatus ::= ENUMERATED { 371 statusOK (0), 372 statusRevoked (1), 373 statusSuperseded (2), 374 statusUnknown (3), 375 ... 376 } 378 In order to provide time information without requiring synchronised clocks 379 (see section 2.6), RTCS uses a relative time value that provides the time as 380 seen by the responder alongside the time at which an event occurred. This 381 eliminates the need for the responder and relying party to have precisely 382 synchronised clocks. The relying party may use the absolute revocation time 383 if they have a mechanism for precise clock synchronisation with the responder, 384 or the difference between the two times to determine how far in the past 385 relative to its own clock the revocation took place. 387 RelativeTimeInfo ::= SEQUENCE { 388 localTime GeneralizedTime, 389 timeValue GeneralizedTime 390 } 392 3.2.2.1 Extended status OK 394 This status value is identical to the basic response equivalent and indicates 395 that the certificate is valid right now. 397 3.2.2.2 Extended status not-OK/revoked 399 If the certificate has been revoked or rendered invalid in some form, the 400 responder will return a "revoked" response. Note that the terminology used 401 here is somewhat misleading in that this response corresponds to a "not OK" 402 response, but in X.509 terms this is usually thought of in terms of revocation 403 so this response is named a "revoked" response: 405 RevocationInfo ::= SEQUENCE { 406 revocationTime RelativeTimeInfo OPTIONAL, 407 revocationReason CRLReason OPTIONAL 408 } 410 revocationTime indicates the time at which the revocation or invalidation 411 took place, if available. 413 revocationReason provides the reason why the certificate was revoked or 414 rendered invalid, if available. 416 3.2.2.3 Extended status superseded 418 If the certificate has been replace by an updated certificate and the 419 replacement is available, the responder MAY return the updated certificate 420 instead of a pure not-OK response: 422 SupersededInfo ::= SEQUENCE { 423 replacementTime [0] RelativeTimeInfo OPTIONAL, 424 replacementReason CRLReason OPTIONAL 425 replacementCert Certificate 426 } 428 The time and reason have the same meaning as for RevocationInfo. 430 The replacementCert is the certificate that has superseded the one being 431 queried. 433 3.2.2.4 Extended status unknown 435 This status value indicates that the queried object doesn't exist. Note that 436 this differs from the standard OCSP "unknown" response, which could mean all 437 manner of things (see section 2.2). 439 3.2.3 Implementation notes and rationale 441 The response returned is not intended to be an intrusion into DPD/DPV 442 territory, but simply represents the only response an authenticated dictionary 443 can return. Just as a CRL can only say with certainty "revoked", so an 444 authenticated dictionary can only say with certainty "present" (and 445 conversely, "not present"). 447 The returned status value meets the requirements in section 2.2 (use of an 448 unambiguous status value) and section 2.6 (no reliance on synchronised 449 clocks). The basic response meets the requirements in section 2.4 (use in 450 resource-constrained environments) as well as being the response type of 451 choice in environments where the relying party only cares about a yes/no 452 indicator. This follows the credit card authorisation model, where the 453 merchant only really cares about accepted/declined, and not a 15-page 454 financial statement about why the transaction wasn't accepted. The response 455 format meets the requirements in section 2.3 (lightweight/realtime operation) 456 since it allows heavyweight signatures or lightweight MACs to be used as 457 required. 459 For relying parties requiring full information, the extended response provides 460 further details. 462 The superseded response anticipates the request that will immediately follow a 463 not-OK response to a status query, "What cert should I use instead, then?". 464 When the RTCS responder is being fed directly from a certificate store, it can 465 trivially obtain the replacement certificate directly from the store and 466 return it to the client as an indication of which certificate replaces the one 467 the client received the not-OK response for. 469 A resource-constrained environment may request a basic response and copy the 470 status directly from a fixed location in the response. This makes RTCS 471 amenable for use in crypto tokens or mobile devices that don't have the 472 resources to handle a full OCSP implementation. 474 3.2.4 High-speed/High-volume Responder Design 476 The simple yes/no response option may be used in applications where a high- 477 speed response is required or a high volume of transactions is expected. 478 Observe that the certHash identifier consitutes the application of a high- 479 quality hash function, which should give a perfectly flat distribution of hash 480 values, with all the work being performed by the client. The responder merely 481 has to select n bits of the hash value and perform a lookup in a table of 2^n 482 bits (with appropriate handling of hash chaining/overflows, this is a standard 483 problem from the literature). This means of implementing an OCSP responder is 484 probably the fastest certificate status query mechanism possible. 486 The use of the CMS format allows further optimisation for high-speed 487 operation, either by taking advantage of hardware acceleration of by using 488 low-overhead MACs instead of high-overhead signatures. PKCS #11 [PKCS11] 489 directly supports the CMS message format, allowing responses to be generated 490 directly by the crypto hardware. Alternatively, CMS supports the use of MACs 491 rather than signatures, allowing responses to be generated with minimal 492 overhead in resource-constrained or high-volume applications. 494 Various network efficiency considerations need to be taken into account when 495 implementing this certificate distribution mechanism. For example, a 496 simplistic implementation that performs two writes (the HTTP header and the 497 certificate written seperately) followed by a read will interact badly with 498 TCP delayed-ACK and slow-start. This occurs because the TCP MSS is typically 499 1460 bytes on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers 500 are ~200-300 bytes, far less than the MSS. When an HTTP message is first 501 sent, the TCP congestion window begins at one segment, with the TCP slow-start 502 then doubling its size for each ACK. Sending the headers separately will send 503 one short segment and a second MSS-size segment, whereupon the TCP stack will 504 wait for the responder's ACK before continuing. The responder gets both 505 segments, then delays its ACK for 200ms in the hopes of piggybacking it on 506 responder data, which is never sent since it's still waiting for the rest of 507 the HTTP body from the initiator. This behvaiour results in a 200ms (+ 508 assorted RTT) delay in each message sent. 510 There are various other considerations that need to be taken into account in 511 order to provide maximum efficiency. These are covered in depth elsewhere 512 [Spero] [Heidemann] [Nielsen]. In addition, modifications to TCP's behaviour 513 such as the use of 4K initial windows [RFC3390] (designed to reduce small HTTP 514 transfer times to a single RTT) should also ameliorate some of these issues. 516 A rule of thumb for optimal performance is to combine the HTTP header and data 517 payload into a single write (any reasonable HTTP implementation will do this 518 anyway, thanks to the considerable body of experience that exists for HTTP 519 server performance tuning), and to keep the HTTP headers to a minimum to try 520 and fit data within the TCP MSS. Since this protocol doesn't involve a web 521 browser, there's no need to include the usual headers covering browser 522 versions and languages and so on; a minimal set of content-type/encoding and 523 host and session control information will suffice. 525 3. Security considerations 527 The legacyID is based on the assumption that DNs in certificates are unique. 528 Although all of X.500 is built upon this assumption, it has been claimed that 529 this may not always be the case. If this is a concern, a DN-based identifier 530 is insufficient to uniquely identify a certificate and the certHash 531 alternative should be used. RTCS always transmits the certHash, so this can 532 always be relied upon to uniquely identify the certificate even in the 533 presence of duplicate, missing, or arbitrarily broken, DNs. 535 References (Normative) 537 [RFC 2119] "Key words for use in RFCs to Indicate Requirement Levels", 538 Scott Bradner, RFC 2119, March 1997. 540 [RFC 3126] "Electronic Signature Formats for long term electronic 541 signatures", Harri Rasilainen, Denis Pinkas, John Ross, 542 Nick Pope, September 2001. 544 [RFC 3369] "Cryptographic Message Syntax (CMS)", Russ Housley, 545 August 2002. 547 [RFC 3379] "Delegated Path Validation and Delegated Path Discovery 548 Protocol Requirements", Denis Pinkas and Russ Housley, 549 RFC 3379, September 2002. 551 [X.680] "Information Technology - Abstract Syntax Notation One", 552 ITU-T Recommendation X.680 (2002) / ISO/IEC 8824-1:2002, 553 2002. 555 References (Informative) 557 [Gutmann] "Lessons Learned in Implementing and Deploying Crypto 558 Software", Peter Gutmann, Proceedings of the 2002 Usenix 559 Security Symposium, August 2002. 561 [Heidemann] "Performance Interactions Between P-HTTP and TCP 562 Implementations", J.Heidemann, ACM Computer Communications 563 Review, April 1997. 565 [Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG", 566 H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie, 567 and C.Lilley, 24 June 1997, 568 http://www.w3.org/Protocols/HTTP/1.0/Performance/Pipeline.html. 570 [PKCS11] "PKCS #11 Cryptographic Token Interface Standard, v2.20", 571 RSA Laboratories, 2003. 573 [RFC3390] "Increasing TCP's Initial Window", RFC 3390, M.Allman, S.Floyd, 574 and C.Partridge, October 2002. 576 [Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994, 577 http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html. 579 Acknowledgements 581 The author would like to thank Denis Pinkas for providing the motivation to 582 finish this draft, members of the RTCS cabal and users of the cryptlib toolkit 583 for feedback on requirements and comments on issues such as use in constrained 584 environments and handling of superseded certificates, Phil Griffin for ASN.1 585 technical advice, and an anonymous PKI architect for the observation that 586 "Learning in 80 ms that the cert was good as of a week ago and to not hope for 587 fresher information for another week seems of limited, if any, utility to us 588 or our customers". 590 Author Address 592 Peter Gutmann 593 University of Auckland 594 Private Bag 92019 595 Auckland, New Zealand 597 Email: pgut001@cs.auckland.ac.nz 599 Full Copyright Statement 601 Copyright (C) The Internet Society (2003). All Rights Reserved. 603 This document and translations of it may be copied and furnished to others, 604 and derivative works that comment on or otherwise explain it or assist in its 605 implementation may be prepared, copied, published and distributed, in whole or 606 in part, without restriction of any kind, provided that the above copyright 607 notice and this paragraph are included on all such copies and derivative 608 works. However, this document itself may not be modified in any way, such as 609 by removing the copyright notice or references to the Internet Society or 610 other Internet organizations, except as needed for the purpose of developing 611 Internet standards in which case the procedures for copyrights defined in the 612 Internet Standards process must be followed, or as required to translate it 613 into languages other than English. 615 The limited permissions granted above are perpetual and will not be revoked by 616 the Internet Society or its successors or assigns. 618 This document and the information contained herein is provided on an "AS IS" 619 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 620 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 621 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 622 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 623 PURPOSE.