idnits 2.17.1 draft-ietf-pkix-ocsp-valid-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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 46 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 62: '...est, one extension MUST have an OID of...' RFC 2119 keyword, line 80: '...nse, responseType MUST have a value of...' RFC 2119 keyword, line 81: '...rsp and response MUST have a value of ...' RFC 2119 keyword, line 92: '...more policy OIDs MAY be included to en...' RFC 2119 keyword, line 95: '...ore certificates MAY be included to ex...' (10 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 159 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 11 errors (**), 0 flaws (~~), 2 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-valid-00.txt Carlisle Adams, Entrust 3 August, 2000 Stephen Farrell, Baltimore 4 Expires in six months 6 Delegated Path Validation 7 draft-ietf-pkix-ocsp-valid-00.txt 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with all pro- 12 visions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1.0 Abstract 31 OCSP [RFC2560] establishes the Internet standard for online certificate status. 32 The baseline response type defined in [RFC2560] supports acquisition of the 33 revocation state of a certificate. This specification builds on the OCSP 34 framework's extensibility by defining an Internet-standard extension to OCSP 35 that can be used to fully delegate all path validation processing to an OCSP 36 server. 38 2.0 Delegated Path Validation 40 In order to determine if a certificate is valid an application must have 41 knowledge of the certificate itself, a set of trusted public keys from which 42 relevant certificate chains may be constructed and the validation status of 43 every certificate used to construct the trust chain. 45 These data may originate from multiple sources. An industry consortium root may 46 issue CA certificates to members of the consortium while members themselves use 47 those CA certificates to either establish subordinate CAs or directly issue end- 48 entity certificates. Equally, a certificate or certificate path established 49 within one trust domain may be "cross certified" into another trust domain. 51 Locating the certificate validation process within a trusted server reduces the 52 technical footprint of certificate using applications and may ease integration 53 of certificate path processing with other authorization data. The Delegated 54 Path Validation (DPV) extension to OCSP addresses this need. 56 A DPV request differs from the basic request defined in [RFC2560] by the 57 inclusion of id-pkix-ocsp-valid-req request OID and request options (if any) as 58 illustrated below (prior knowledge of [RFC2560] is assumed): 60 OCSP REQUEST 61 ------------ 62 In the requestExtensions field of TBSRequest, one extension MUST have an OID of 63 id-pkix-ocsp-valid-req and a value of DPVOptions (see below for syntax). 65 The initialPolicySet option enables a requestor to establish one or more initial 66 policy identifiers as defined in [RFC2459]. 68 The trustPoints option enables specification of one or more certificates 69 relevant to the relying party's trust model. If included, a successful 70 validation request will pass through at least one of these trust points, else an 71 "unknown" response will be generated. 73 A DPV response differs from the basic response defined in [RFC2560] in the 74 substitution of id-pkix-ocsp-valid-rsp for id-pkix-ocsp-basic in the 75 ResponseType field of the ResponseBytes syntax. This is illustrated as follows 76 (again, prior knowledge of [RFC2560] is assumed): 78 OCSP RESPONSE 79 ------------- 80 In the responseBytes field of OCSPResponse, responseType MUST have a value of 81 id-pkix-ocsp-valid-rsp and response MUST have a value of DPVOCSPResponse, where 82 DPVOCSPResponse ::= BasicOCSPResponse 84 4.0 Delegated Path Validation Requirements 86 Relying party software desiring to delegate path validation to an OCSP server 87 SHALL include a value of id-pkix-ocsp-valid-req as a requestExtension in the 88 OCSPRequest syntax defined by [RFC2560]. 90 id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 92 One or more policy OIDs MAY be included to enable policy-based control on the 93 OCSP server's path construction and path validation processes. Definition of 94 any such policies and their corresponding OIDs is beyond the scope of this 95 specification. One or more certificates MAY be included to express trust points 96 relevant to the relying party's trust model. 98 DPVOptions :: = SEQUENCE{ 99 initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 100 trustPoints SEQUENCE OF ReqCert OPTIONAL } 102 If neither initialPolicySet nor trustPoints are included in the request, the 103 DPVOptions structure SHALL omit both optional fields. 105 OCSP servers operated to perform delegated path validation SHALL include a value 106 of id-pkix-ocsp-valid-rsp in the responseType field of the ResponseBytes syntax 107 upon receipt of a request containing a value of id-pkix-ocsp-valid-req as 108 defined above. 110 id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 112 Servers that produce id-pkix-ocsp-valid-rsp responses SHALL execute path 113 validation logic that produces outputs compliant with [RFC2459]. 115 OCSP servers claiming compliance to this specification SHALL support the 116 DPVOptions request syntax as follows. 118 If a request contains a non-NULL value for initialPolicySet, all OIDs included 119 in that set SHALL be used as initial policy identifier values in the validation 120 logic according to [RFC2459]. 122 If a request contains a non-NULL value for trustPoints, the receiving server 123 MUST attempt to produce a response that incorporates at least one of these 124 certificates. If the receiving server cannot form such a path, the server SHALL 125 return a status value of "unknown" in the response. 127 5.0 Security Considerations 129 TBD 131 6.0 Collected Syntax 133 PathValidation DEFINITIONS EXPLICIT TAGS ::= {iso(1) identified-organization(3) 134 dod(6) internet(1) security(5) mechanisms(5) pkix(7) X } 136 BEGIN 138 IMPORTS 140 -- PKIX 141 Extensions 142 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 143 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 144 id-mod(0) id-pkix1-explicit-88(1)} 145 -- OCSP 146 id-pkix-ocsp 147 FROM OCSP {iso(1) identified-organization(3) 148 dod(6) internet(1) security(5) mechanisms(5) pkix(7) X } 150 -- Directory Authentication Framework (X.509) 151 Certificate 152 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 153 module(1) authenticationFramework(7) 3 }; 155 -- Delegated Path Validation request 156 id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 158 DPVOptions :: = SEQUENCE{ 159 initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 160 trustPoints SEQUENCE OF Certificate OPTIONAL } 162 PolicyList ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 164 -- Delegated Path Validation response 165 id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 167 END 169 5. References 171 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C., 172 "X.509 Internet Public Key Infrastructure Online Certificate 173 Status Protocol", RFC 2560 175 [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 176 Public Key Infrastructure - X.509 Certificate and CRL 177 profile", RFC2459. 179 6. Author's Address 181 Michael Myers 182 VeriSign, Inc. 183 mmyers@verisign.com 185 Stephen Farrell 186 Baltimore Technologies 187 stephen.farrell@baltimore.ie 189 Carlisle Adams 190 Entrust Technologies 191 cadams@entrust.com