idnits 2.17.1 draft-ietf-pkix-ocsp-path-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages 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 58 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC2560]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 56: '...est, one extension MUST have an OID of...' RFC 2119 keyword, line 65: '...en the responder MUST NOT return any p...' RFC 2119 keyword, line 66: '...erence (i.e. the responder MUST either...' RFC 2119 keyword, line 73: '...nse, responseType MUST have a value of...' RFC 2119 keyword, line 74: '...rsp and response MUST have a value of ...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 2000) is 8625 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: 'RFC2026' is mentioned on line 13, but not defined -- Looks like a reference, but probably isn't: '0' on line 188 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Michael Myers, VeriSign 2 draft-ietf-pkix-ocsp-path-00.txt Stephen Farrell, Baltimore 3 Expires in six months Carlisle Adams, Entrust 4 September 2000 6 Delegated Path Discovery with OCSP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. Internet-Drafts are draft 17 documents valid for a maximum of six months and may be updated, replaced, or 18 obsoleted by other documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them 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 Abstract 29 OCSP [RFC2560] establishes the Internet standard for online certificate status. 30 An OCSP path discovery responder is an enhanced OCSP responder that provides 31 requestors with certification paths. The technological and geographic diversity 32 of the sources of these data motivates existence of service that enables 33 relying-party software to acquire certification path data from an OCSP server 34 rather than replicate the same functionality. This specification establishes an 35 Internet standard extension to OCSP to address this need. 37 1. Delegated Path Discovery 39 The path validation logic defined by [RFC2459] requires certificate-processing 40 systems to accumulate the set of certificates from which certificate chains may 41 be constructed as well as revocation data for each such certificate. These data 42 may originate from diverse sources. Commonly used technologies for retrieving 43 this information include X.500, LDAP, HTTP, FTP and SMTP as well as proprietary 44 methods. Delegating this acquisition process to a separate server greatly 45 simplifies and reduces the size of public-key based credential validation 46 systems or other relying party software. It may also be useful to such software 47 to be able to select from among various trust paths in the event multiple paths 48 exist. The Delegated Path Discovery (DPD) extension to OCSP addresses these 49 needs. 51 The DPD extension to OCSP request applies to the requestExtensions syntax of the 52 OCSP request as outlined below (prior knowledge of [RFC2560] is assumed): 54 OCSP REQUEST 55 ------------ 56 In the requestExtensions field of TBSRequest, one extension MUST have an OID of 57 id-pkix-ocsp-path-req and a value of RetryReference, where 59 RetryReference ::= OCTET STRING 61 The RetryReference enables a requestor to acquire the next of potentially 62 several valid paths known to the OCSP server based on a previous response. If 63 this field is omitted then the request is considered to be a "new" request and 64 the responder may return any path that meets the request criteria. If a client 65 does specify a RetryReference then the responder MUST NOT return any path that 66 was previously returned with that reference (i.e. the responder MUST either 67 return a different path meeting the request or an error). 69 A DPD response consists of the following information: 71 OCSP RESPONSE 72 ------------- 73 In the responseBytes field of OCSPResponse, responseType MUST have a value of 74 id-pkix-ocsp-path-rsp and response MUST have a value of DPDOCSPResponse, where 76 DPDOCSPResponse ::= SEQUENCE OF PathResponse 77 -- one for each certificate included in the requestList field of TBSRequest 79 PathResponse ::= SEQUENCE { 80 retryReference BIT STRING, 81 certificates SEQUENCE OF Certificate, 82 crls SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL, 83 ocspReps SEQUENCE SIZE (1..MAX) OF OCSPResponse OPTIONAL 84 } 86 The sequence of certificates MUST form a potentially valid certification path, 87 in order, from end-entity certificate (element 0 of the sequence), up to and 88 including a "final" CA certificate, (which need not, but MAY be self-certified). 90 The RetryReference SHOULD uniquely refer to all path validation data (including 91 the data in the current response) that has been returned to the requester with 92 respect to this request. 94 The responder MAY also include a set of CRLs and/or OCSP responses which, if 95 included, SHOULD relate to the certificates in the set of certificates. 97 2. Conformance Requirements 99 An OCSP server claiming compliance to this specification SHALL: 101 1. Upon receipt of an authorized path discovery request, where possible, deliver 102 to the requestor a collection of certificates and optionally CRLs and other OCSP 103 responses that may be used to validate a certificate according to [RFC2459]; 104 2. Either establish a stateful association enabling a requestor to serially ask 105 for the next path via the retry option, to the extent that multiple validation 106 paths exist and the receiving OCSP server is aware of these paths or respond 107 with a noStateMaintained error to all retry requests if the server does not 108 maintain state; and 110 3. In the event that the server is stateful and a prior response was the last 111 path known to the responder, respond to subsequent retry requests with a 112 noMoreData value in OSCPResponseStatus. 114 Requestors and responders SHALL at a minimum support the issuerSerial 115 identification form of the ReqCert syntax of OCSP. Other identification forms 116 MAY be supported according to local needs. 118 3. Security Considerations 120 A responder that only supports this service need not be trusted by a client for 121 certificate status since it only supplies data that is signed by CAs. However, 122 the client is trusting the responder to make an "honest effort" to find a path 123 (or an additional path, if more than one exist). Since the client is presumably 124 using the certificates for some important function, denial-of-service attacks on 125 the responder are still potentially very serious and implementers should take 126 steps to ensure the robustness of their implementations. 128 MORE TBD 130 4. References 132 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C., 133 "X.509 Internet Public Key Infrastructure Online Certificate 134 Status Protocol", RFC 2560 136 [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 137 Public Key Infrastructure - X.509 Certificate and CRL 138 profile", RFC2459. 140 5. Author's Addresses 142 Michael Myers 143 VeriSign, Inc. 144 mmyers@verisign.com 146 Stephen Farrell 147 Baltimore Technologies 148 stephen.farrell@baltimore.ie 150 Carlisle Adams 151 Entrust Technologies 152 cadams@entrust.com 153 Appendix A : Collected Syntax 155 PathDiscovery DEFINITIONS EXPLICIT TAGS ::= 156 {iso(1) identified-organization(3) 157 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 158 X -- TBS -- } 160 BEGIN 162 IMPORTS 164 -- PKIX 165 Certificate, CertificateList 166 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 167 dod(6) internet(1) security(5) mechanisms(5) 168 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 170 -- OCSP 171 id-pkix-ocsp 172 FROM OCSP {iso(1) identified-organization(3) 173 dod(6) internet(1) security(5) mechanisms(5) 174 pkix(7) X -- TBD -- }; 176 -- Delegated Path Discovery request 177 id-pkix-ocsp-path-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 179 -- the only indicator in the request 180 RetryReference ::= OCTET STRING --return next path, if one exists } 182 -- Delegated Path Discovery response 183 id-pkix-ocsp-path-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 185 DPDResponse :: = SEQUENCE { 186 ref RetryReference, 187 certs SEQUENCE OF Certificate, 188 crls [0] SEQUENCE OF CertificateList OPTIONAL, 189 otherResps SEQUENCE OF OCSPResponse OPTIONAL} 191 END