idnits 2.17.00 (12 Aug 2021) /tmp/idnits56024/draft-gutmann-pkix-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? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- 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 491 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 157 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 (December 2002) is 7097 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 61, but not defined -- Looks like a reference, but probably isn't: '2' on line 141 -- Looks like a reference, but probably isn't: '0' on line 370 == Unused Reference: 'RFC 2119' is defined on line 434, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Gutmann' ** 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: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P.Gutmann 2 draft-gutmann-pkix-ocsp-rtcs-00.txt University of Auckland 3 Expires in 6 months December 2002 5 X.509 Internet Public Key Infrastructure 6 Real-time Certificate Status Facility for OCSP - (RTCS) 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 RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and may 18 be updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet- Drafts as reference material or to cite them 20 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 Copyright Notice 30 Copyright (C) The Internet Society (1999-2002). All Rights Reserved. 32 1. Abstract 34 When the OCSP protocol was defined, the design was based on full compatibility 35 with CRL-based mechanisms. This requires the use of a complex means of 36 certificate identification that has resulted in interoperability problems 37 among implementations, the inability to provide an unambiguous certificate 38 status response (the only thing that a CRL can say with certainty is 39 "revoked"), and an online responder tied to an offline mechanism (some CAs 40 issue CRLs only once or twice a day, even though they have an online, real- 41 time certificate store available). 43 Fortunately, the authors of the OCSP RFC foresaw this situation by allowing a 44 client to specify, and a responder to return, more than one type of response. 45 Just as the original OCSP responses were designed for completely CRL- 46 compatible operation, this document specifies a response type that is designed 47 for real-time status operation, providing a response not from a stored CRL 48 using CRL-only mechanisms but directly from a live certificate store. This 49 allows the responder to provide extended information not possible with CRLs. 51 In abstract terms, the responder is providing an implementation of an 52 authenticated dictionary that responds to membership queries from relying 53 parties. A conventional OCSP responder answers the question "Is x excluded 54 from D?", while an OCSP responder with RTCS capability answers the question 55 "Is x present in D?". 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 58 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 59 uppercase, as shown) are to be interpreted as described in [RFC2119] ,except 60 when they appear in ASN.1 constructs, in which case they follow [X.680] 62 2. Problem analysis 64 This section examines the problems that need to be solved by the protocol, and 65 provides a rationale for design decisions. The next section defines the 66 protocol based on the design decisions. 68 2.1 Certificate identification 70 OCSP defines a complex certificate identifier that takes portions of the 71 certificate, hashes some (making reference to the original value impossible), 72 doesn't hash others, and even requires a hash of data from other certificates 73 to be included as part of the identifier, making it impossible to query the 74 status of a single, standalone certificate. Real-world experience has shown 75 that implementors have considerable difficulty with this identifier, leading 76 to interoperability problems among implementations. 78 A major design goal of RTCS then is to provide a simple, widely-accepted, 79 universally-applicable identifier for all certificates, regardless of their 80 schema or encoding. For compatibility with legacy implementations, it also 81 provides a CRL-compatible identifier, although there are some caveats attached 82 to its use (see section 3.1). 84 2.2 Returned status value 86 Because of its CRL-based origins, OCSP can only return a negative response. 87 For example, when fed a freshly-issued certificate and asked "Is this a valid 88 certificate", it can't say "Yes" (a CRL can only answer "revoked"), and when 89 fed an Excel spreadsheet it can't say "No" (the spreadsheet won't be present 90 on any CRL). This problem interacts badly with the one in section 2.1 in that 91 an unknown response could mean anything from "I couldn't find a CRL for this 92 certificate" to "I don't know the status of this certificate" to "This may 93 well be a valid certificate but your software and mine disagree over how to 94 generate the identifier", and there is no way to determine what the actual 95 problem is. 97 The second major design goal of RTCS then is to provide a clear, unambiguous 98 response to any query, either "This certificate is definitely valid right 99 now", "This certificate is definitely not valid right now", or "The object you 100 have queried doesn't exist". 102 2.3 Use in constrained environments 104 The protocol should be capable of running in resource- or bandwidth- 105 constrained environments. In its most minimal implementation, RTCS has a 106 small number of fixed-length fields, allowing it to be used by dropping data 107 into pre-generated PDUs. The very small message size and minimal processing 108 requirements make it ideal for use with mobile and remote devices, high-volume 109 transaction systems, and in other constrained environments. 111 2.4 Reliance on synchronised clocks 113 OCSP uses timestamps for all responses, assuming that the relying party and 114 responder somehow have perfectly synchronised clocks. This is almost never 115 the case, with systems having been encounted with clocks that are as much as 116 decades out of sync [Gutmann]. RTCS, almost by definition, does not rely on 117 synchronised clocks for its operation. 119 3. RTCS 121 RTCS is designed to provide online, real-time certificate status information 122 by directly reference to a certificate store, in a manner that meets the 123 design goals given in section 2. 125 3.1 RTCS requests 127 RTCS makes use of the OCSP AcceptableResponses extension to specify the 128 response types that it will accept. There are two response types, a simple 129 basic status value suitable for use when only a yes/no response is required or 130 in resource-constrained environments, and an extended response type suitable 131 for use when more information is required. 133 The response types are identified by: 135 id-pkix-rtcs-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp TBA } 136 id-pkix-rtcs-extended OBJECT IDENTIFIER ::= { id-pkix-ocsp TBA+1 } 138 In order to identify the certificate, RTCS extends the existing OCSP 139 identifiers to use the following new identifier type: 141 RtcsIdentifier ::= [2] SEQUENCE { 142 certHash OtherHash, 143 legacyID IssuerAndSerialNumber OPTIONAL 144 } 146 certHash is an SHA-1 hash of the certificate. Almost everything implements 147 this (variously as "fingerprint" or "thumbprint" or under some similar 148 name), the ID type is widely recognised, and interoperability/correctness 149 checking is trivial to achieve. The full definition of OtherHash is given 150 in [RFC 3126], however as used here it SHOULD be regarded as a pure 151 sha1Hash: 153 sha1Hash ::= OCTET STRING SIZE(20) 155 legacyID is provided when backwards-compatibility with CRL-based legacy 156 implementations are required. The full definition is given in [RFC 3369]. 157 This identifier is widely used in CMS and S/MIME, and may be trivially 158 generated from any X.509 certificate. This identifier MUST be included 159 when it is known that the responder is a legacy implementation, and SHOULD 160 be used when the client is unclear as to the status of the responder. It 161 MAY be omitted in resource-constrained environments, or when the client 162 knows that the responder is capable of handling the certHash. See the 163 security considerations for a note on this identifier type. 165 Note that the tagging is used to ensure non-interference with existing OCSP 166 identifiers. 168 3.1.1 Additional requirements 170 Since RTCS doesn't depend on synchronised clocks, implementations MUST use the 171 OCSP Nonce extension to ensure freshness of replies. 173 3.1.2 Implementation notes and rationale 175 The certHash identifier meets the requirements in section 2.1 (use of a 176 widely-accepted, simple, universal identifier for certificates) and section 177 2.3 (ability to be used in a constrained environment). 179 The certificate hash is a universal identifier in that it doesn't care what 180 type or version of certificate is used, whether it's encoded in DER or XER, or 181 whether the certificate even has a DN. It works with X.509 certificates (v1, 182 v2, or v3) with or without extensions, X.509 attribute certificates (v1 or 183 v2), special-case certificates such as X9.68 domain certificates, and any 184 other certificate or certificate-like object that may appear in the future. 185 The hash does not require writing, testing, documenting and maintaining the 186 programming logic needed to handle DN complexity, and is immune to DN-based 187 problems that affect OCSP. 189 The backup legacyID may be used with CRL-based legacy implementations, or in 190 situations where the certificate store is implemented as an LDAP directory 191 that identifies certificates by DN. This ensures full backwards compatibility 192 with CRL-based implementations. 194 A resource- or bandwidth-constrained environment may use a pre-generated OCSP 195 query and copy the certHash directly into a fixed location in the query. This 196 makes RTCS amenable for use in crypto tokens or mobile devices or high-volume 197 transaction systems that don't have the resources to handle a full OCSP 198 implementation and that merely populate a pre-generated query with a fresh 199 nonce and 20-byte certHash. 201 The full definition of OtherHash, from [RFC 3126], is: 203 OtherHash ::= CHOICE { 204 sha1Hash OCTET STRING SIZE(20), 205 otherHash OtherHashAlgAndValue 206 } 208 OtherHashAlgAndValue ::= SEQUENCE { 209 hashAlgorithm AlgorithmIdentifier, 210 hashValue OCTET STRING 211 } 213 The intent here is that if a weakness is found in SHA-1, an alternative hash 214 algorithm may be substituted in its place. Since every Internet security 215 protocol ever created would require rewriting if SHA-1 was broken, this is 216 probably a lesser concern, but an alternative is provided here anyway. In 217 standard usage the above simplies to a straight SHA-1 hash. 219 3.2 RTCS response 221 RTCS defines two response types, a basic response when only a simple yes/no 222 status is required, and a full response when extended information is required. 224 [Editorial note: These are currently defined in modern ASN.1 for convenience, 225 but can be back-ported to ASN.1 '88 (ugh, and with a lot of additional text 226 to cover the stuff '88 can't do) later. The following simply say what OCSP 227 says with a large amount of text, but in a manner directly usable with an 228 ASN.1 compiler, E&OE] 230 RTCSRESPONSE ::= TYPE-IDENTIFIER 232 RtcsResponseBytes ::= SEQUENCE { 233 type RTCSRESPONSE.&id({ RtcsResponseTypes }), 234 response OCTET STRING (CONTAINING RtcsResponse) 235 } 237 RtcsResponse ::= SEQUENCE { 238 tbsResponseData RTCSRESPONSE.&Type({ RtcsResponseTypes }{ @.type-id }) 239 signatureAlgorithm AlgorithmIdentifier OPTIONAL, 240 signature BIT STRING OPTIONAL, 241 certs Certificates OPTIONAL 242 } 244 RtcsResponseTypes RTCSRESPONSE ::= { 245 rtscResponseBasic | rtscResponseExtended, 246 ... 247 } 249 rtcsResponseBasic RTSCRESPONSE ::= { 250 SYNTAX RtcsResponeBasic ID { id-pkix-rtcs-basic } 251 } 253 rtcsResponseExtended RTSCRESPONSE ::= { 254 SYNTAX RtcsResponeExtended ID { id-pkix-rtcs-extended } 255 } 257 SignedResponseClass ::= Response 258 ( WITH COMPONENTS { 259 tbsResponseData( SignedResponseData ) PRESENT, 260 signatureAlgorithm PRESENT, 261 signature PRESENT } ) 263 UnsignedResponseClass ::= Response 264 ( WITH COMPONENTS { 265 tbsResponseData( UnsignedResponseData ) PRESENT } ) 267 SignedResponseData ::= ResponseData 268 ( WITH COMPONENTS { 269 ..., responderID PRESENT } ) 271 UnsignedResponseData ::= ResponseData 272 ( WITH COMPONENTS { 273 ..., responderID ABSENT } ) 275 3.2.1 RTCS basic response 277 This is a straightforward yes/no response type: 279 RtcsResponseBasic ::= SEQUENCE { 280 certHash OtherHash, 281 status BOOLEAN, 282 extensions Extensions OPTIONAL 283 } 285 A returned value 'true' indicates that the certificate is valid right now. A 286 returned value 'false' indicates that the certificate is not valid right now. 287 This is a clear, unambiguous response that is useful for relying parties who, 288 having a certificate at hand, simply want to know whether they can safely use 289 it or not, and no more. Relying parties who require further information 290 SHOULD use the extended response in section 3.2.2. 292 3.2.2 RTCS extended response 294 This is an extended response type returning more information than the basic 295 RTCS response: 297 RESPONSEINFO ::= CLASS { 298 &status CertStatus UNIQUE, 299 &StatusInfo OPTIONAL 300 } WITH SYNTAX { &status [WITH DETAILS IN &StatusInfo] } 302 RtcsResponseExtended ::= SEQUENCE { 303 certHash OtherHash, 304 status RESPONSEINFO.&status({ CertStatus }), 305 statusInfo RESPONSEINFO.&StatusInfo({ CertStatus }{ @status }), 306 extensions Extensions OPTIONAL 307 } 309 ResponseTypes RESPONSEINFO ::= { 310 { statusOK } | 311 { statusRevoked WITH DETAILS IN RevocationInfo } | 312 { statusSuperseded WITH DETAILS IN SupersededInfo } | 313 { statusUnknown }, 314 ... 315 } 317 CertStatus ::= ENUMERATED { 318 statusOK (0), 319 statusRevoked (1), 320 statusSuperseded (2), 321 statusUnknown (3), 322 ... 323 } 325 In order to provide time information without requiring synchronised clocks 326 (see section 2.4), RTCS uses a relative time value that provides the time as 327 seen by the responder alongside the time at which an event occurred. This 328 eliminates the need for the responder and relying party to have precisely 329 synchronised clocks. The relying party may use the absolute revocation time 330 if they have a mechanism for precise clock synchronisation with the responder, 331 or the difference between the two times to determine how far in the past 332 relative to its own clock the revocation took place. 334 RelativeTimeInfo ::= SEQUENCE { 335 localTime GeneralizedTime, 336 timeValue GeneralizedTime 337 } 339 3.2.2.1 Extended status OK 341 This status value is identical to the basic response equivalent and indicates 342 that the certificate is valid right now. 344 3.2.2.2 Extended status not-OK/revoked 346 If the certificate has been revoked or rendered invalid in some form, the 347 responder will return a "revoked" response. Note that the terminology used 348 here is somewhat misleading in that this response corresponds to a "not OK" 349 response, but in X.509 terms this is usually thought of in terms of revocation 350 so this response is named a "revoked" response: 352 RevocationInfo ::= SEQUENCE { 353 revocationTime RelativeTimeInfo OPTIONAL, 354 revocationReason CRLReason OPTIONAL 355 } 357 revocationTime indicates the time at which the revocation or invalidation 358 took place, if available. 360 revocationReason provides the reason why the certificate was revoked or 361 rendered invalid, if available. 363 3.2.2.3 Extended status superseded 365 If the certificate has been replace by an updated certificate and the 366 replacement is available, the responder MAY return the updated certificate 367 instead of a pure not-OK response: 369 SupersededInfo ::= SEQUENCE { 370 replacementTime [0] RelativeTimeInfo OPTIONAL, 371 replacementReason CRLReason OPTIONAL 372 replacementCert Certificate 373 } 375 The time and reason have the same meaning as for RevocationInfo. 377 The replacementCert is the certificate that has superseded the one being 378 queried. 380 3.2.2.4 Extended status unknown 382 This status value indicates that the queried object doesn't exist. Note that 383 this differs from the standard OCSP "unknown" response, which could mean all 384 manner of things (see section 2.2). 386 3.2.3 Implementation notes and rationale 388 The returned status value meets the requirements in section 2.2 (use of an 389 unambiguous status value) and section 2.4 (no reliance on synchronised 390 clocks). The basic response meets the requirements in section 2.3 (use in 391 resource-constrained environments) as well as being the response type of 392 choice in environments where the relying party only cares about a yes/no 393 indicator. This follows the credit card authorisation model, where the 394 merchant only really cares about accepted/declined, and not a 15-page 395 financial statement about why the transaction wasn't accepted. 397 For relying parties requiring full information, the extended response provides 398 further details. 400 The superseded response anticipates the request that will immediately follow a 401 not-OK response to a status query, "What cert should I use instead, then?". 402 When the RTCS responder is being fed directly from a certificate store, it can 403 trivially obtain the replacement certificate directly from the store and 404 return it to the client as an indication of which certificate replaces the one 405 the client received the not-OK response for. 407 A resource-constrained environment may request a basic response and copy the 408 status directly from a fixed location in the response. This makes RTCS 409 amenable for use in crypto tokens or mobile devices that don't have the 410 resources to handle a full OCSP implementation. 412 3. Security considerations 414 The legacyID is based on the assumption that DNs in certificates are unique. 415 Although all of X.500 is built upon this assumption, it has been claimed that 416 this may not always be the case. If this is a concern, a DN-based identifier 417 is insufficient to uniquely identify a certificate and the certHash 418 alternative should be used. RTCS always transmits the certHash, so this can 419 always be relied upon to uniquely identify the certificate even in the 420 presence of duplicate, missing, or arbitrarily broken, DNs. 422 When returning a response, the responder is merely indicating that the queried 423 certificate is currently present in its set of valid certificates. It is 424 purely an authenticated dictionary service and does not verify the certificate 425 in any way. Relying parties requiring external verification services should 426 use the PKIX standard mechanisms for this [RFC 3379] and not RTCS. 428 References 430 [Gutmann] "Lessons Learned in Implementing and Deploying Crypto Software" 431 Peter Gutmann, Proceedings of the 2002 Usenix Security Symposium, 432 August 2002. 434 [RFC 2119] "Key words for use in RFCs to Indicate Requirement Levels", Scott 435 Bradner, RFC 2119, March 1997. 437 [RFC 3126] "Electronic Signature Formats for long term electronic signatures", 438 Harri Rasilainen, Denis Pinkas, John Ross, Nick Pope, September 439 2001. 441 [RFC 3369] "Cryptographic Message Syntax (CMS)", Russ Housley, August 2002. 443 [RFC 3379] "Delegated Path Validation and Delegated Path Discovery Protocol 444 Requirements", Denis Pinkas and Russ Housley, RFC 3379, 445 September 2002. 447 [X.680] "Information Technology - Abstract Syntax Notation One", ITU-T 448 Recommendation X.680 (2002) / ISO/IEC 8824-1:2002, 2002. 450 Acknowledgements 452 The author would like to thank Denis Pinkas for providing the motivation to 453 finish this draft, and users of the cryptlib toolkit for feedback on 454 requirements and comments on issues such as use in constrained environments 455 and handling of superseded certificates. 457 Author Address 459 Peter Gutmann 460 University of Auckland 461 Private Bag 92019 462 Auckland, New Zealand 464 EMail: pgut001@cs.auckland.ac.nz 466 Full Copyright Statement 468 Copyright (C) The Internet Society (2002). All Rights Reserved. 470 This document and translations of it may be copied and furnished to others, 471 and derivative works that comment on or otherwise explain it or assist in its 472 implementation may be prepared, copied, published and distributed, in whole or 473 in part, without restriction of any kind, provided that the above copyright 474 notice and this paragraph are included on all such copies and derivative 475 works. However, this document itself may not be modified in any way, such as 476 by removing the copyright notice or references to the Internet Society or 477 other Internet organizations, except as needed for the purpose of developing 478 Internet standards in which case the procedures for copyrights defined in the 479 Internet Standards process must be followed, or as required to translate it 480 into languages other than English. 482 The limited permissions granted above are perpetual and will not be revoked by 483 the Internet Society or its successors or assigns. 485 This document and the information contained herein is provided on an "AS IS" 486 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 487 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 488 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 489 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 490 PURPOSE.