Ballot for draft-ietf-lamps-rfc5019bis
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
This document updates and re-uses text from a pre2008 RFC, so it needs to use the pre5378Trust200902 boilerplate. Otherwise, the document looks good. See https://www.rfc-editor.org/rfc/rfc7991.html#appendix-A.1.1.4
I have only one comment: Section 3.2.2, Appendix A: The two terms 'byName' and 'byKey' are used without being defined (note: this is true in RFC 5019 too). There are numerous 'Name' fields in the ASN.1, but no 'Key' fields. My suggestion is to define these terms by pointing to the appropriate ASN.1 field. [note: finally, I get to ballot on a document I understand. LOL]
# Internet AD comments for draft-ietf-lamps-rfc5019bis-08 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### Appendix B.5 * Out of curiosity, what causes the different formats for the time strings: - "GeneralizedTime 10/04/2024 12:37:47 GMT", and - "UTCTime 02/04/2024 12:37:47 GMT"? Clearly they're both GMT, and therefore compliant with S3.2.4. I'm just curious...
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc5019bis-08 Thank you for the work put into this document. Please find below some non-blocking COMMENT points. I hope that this review helps to improve the document, 117 (For brevity we refer to OCSP as being used to verify certificate 118 status, but only the revocation status of a certificate is checked 119 via this protocol.) As networking generalist i am unclear what the 'but only' refers towards? it reads a bit odd. in addition not sure if the word 'we' helps in a formal document. What about following rewrite suggestion: For brevity, the term "OCSP" is used herein to denote the verification of certificate status; however, it should be noted that this protocol is employed solely to ascertain the revocation status of a certificate. 121 To date, many OCSP deployments have been used to ensure timely and 122 secure certificate status information for high-value electronic 123 transactions or highly sensitive information, such as in the banking 124 and financial environments. As such, the requirement for an OCSP This text processes difficult for me. Would he following text be a potential rewrite? To date, numerous OCSP deployments have been implemented to provide timely and secure certificate status information, crucial for high-value electronic transactions and the handling of highly sensitive information, particularly within the banking and financial sectors. 128 is not an issue, and have run on client and server systems where 129 processing power is not constrained. I assume that there is no additional constraints beyond the capabilities of the CPU/memory used? 151 This document addresses the scalability issues inherent when using 152 OCSP in PKI environments described above by defining a message 153 profile and clarifying OCSP client and responder behavior that will 154 permit: Instead of writing 'in PKI environments described above' would it not be more simpler to say 'in highly scaled PKI environments'? 668 8. Security Considerations Is there a special fallback consideration in scenarios where the OCSP check fails (either due to responder issues or network problems)? Are there any additional privacy considerations associated with the lightweight solution beyond those already noted for the traditional OCSP? G/
Where you say "header", I believe you mean "header field", especially below Section 7.
# Orie Steele, ART AD, comments for draft-ietf-lamps-rfc5019bis-08 CC @OR13 This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues, or using this [online validator](https://mnot.github.io/ietf-comments/). Line numbers are generated with this: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5019bis-08.txt&submitcheck=True ## Comments ### Section 1 profile discovery ``` 169 OCSP does not have the means to signal responder capabilities within 170 the protocol. Thus, clients will need to use out-of-band mechanisms 171 to determine whether a responder conforms to the profile defined in 172 this document. Regardless of the availability of such out-of-band 173 mechanisms, this profile ensures that interoperability will still 174 occur between an OCSP client that fully conforms with [RFC6960] and a 175 responder that is operating in a mode as described in this 176 specification. ``` Consider documenting at least 1 out of band mechanism in an appendix? ### Section 3.1.1 missing Signature ``` 194 Provided for convenience here, but unchanged from [RFC6960], the 195 ASN.1 structure corresponding to the OCSPRequest with the relevant 196 CertID is: ``` https://datatracker.ietf.org/doc/html/rfc6960#section-4.1.1 contains: ``` Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} ``` But this section does not. I am not sure if this impacts "copy paste / validation", but it is a "change" that I noticed. Later sections note that unsigned requests are acceptable, perhaps this is the reason for the ommision? ### Section 3.1.1 which AlgorithmIdentifier is used for SHA-256? ``` 221 The CertID.issuerNameHash and CertID.issuerKeyHash fields contain 222 hashes of the issuer's DN and public key, respectively. OCSP clients 223 that conform with this profile MUST use SHA-256 as defined in 224 [RFC6234] as the hashing algorithm for the CertID.issuerNameHash and 225 the CertID.issuerKeyHash values. ``` I wondered if there is a better reference for the AlgorithmIdentifier that is SHA-256. Something more ASN.1 specific? ### sha-1 still ok? In Section 3.1.1: ``` 230 However, these OCSP clients should transition from SHA-1 to SHA-256 231 as soon as practical. ``` Capitalize SHOULD? Why not MUST? (given the as soon as practical comment) Later in security considerations: ``` 749 8.7. Use of SHA-1 for the calculation of CertID field values 751 Although the use of SHA-1 for the calculation of CertID field values 752 is not of concern from a cryptographic security standpoint, the 753 continued use of SHA-1 in an ecosystem requires that software that 754 interoperates with the ecosystem maintain support for SHA-1. This 755 increases implementation complexity and potential attack surface for 756 the software in question. Thus, the continued use of SHA-1 in an 757 ecosystem to maintain interoperability with legacy software must be 758 weighed against the increased implementation complexity and potential 759 attack surface. ``` 8.7 framing reads as "no rush", which does not seem like a security consideration. ### Section 3.1.2 ignore requestorName? ``` 246 If the OCSPRequest is signed, the client SHALL specify its name in 247 the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT 248 include the requestorName field in the OCSPRequest. OCSP servers 249 MUST be prepared to receive unsigned OCSP requests that contain the 250 requestorName field, but MUST handle such requests as if the 251 requestorName field were absent. ``` Why not "clients MUST NOT include the requestorName field in the OCSPRequest" ? Wording of the second part could also be clearer, something like: ``` 248 include the requestorName field in the OCSPRequest. OCSP servers 249 MUST handle unsigned OCSP requests that contain the 250 requestorName field, as if the requestorName field were absent. ``` ### Section 3.2.3 resource exhaustion? ``` 382 Also, in order to ensure the database of revocation information does 383 not grow unbounded over time, the responder MAY remove the status 384 records of expired certificates. Requests from clients for ``` Why not SHOULD? Under what circumstances SHOULD the status records for expired certificates be retained indefinitely? ### Section 3.2.4 redundant MUST? ``` 400 available about the status of the certificate. Responders MUST 401 always include this value to aid in response caching. See 402 Section 7 for additional information on caching. ``` The MUST here seems redundant? Are these fields always present, or optional except for this one? The text in later sections implies these are all mandatory. ### Section 4.2 expiration checks ``` 439 Similarly, an application MUST validate the signature on certificates 440 in a chain, before asking an OCSP client to check the status of the 441 certificate. If the certificate signature is invalid or the 442 application is not able to verify it, an OCSP check MUST NOT be 443 requested. Clients SHOULD NOT make a request to check the status of 444 expired certificates. ``` Why not MUST NOT? Consider: ``` 441 certificate. If the certificate signature is invalid or the 442 application is not able to verify it, or the certificate is expired, 443 an OCSP check MUST NOT be requested. ``` ### Section 6 HTTP vs HTTPs ``` 492 6. Transport Profile 494 OCSP clients can send HTTP-based OCSP requests using either the GET 495 or POST method. The OCSP responder MUST support requests and 496 responses over HTTP. When sending requests that are less than or 497 equal to 255 bytes in total (after encoding) including the scheme and 498 delimiters (http://), server name and base64-encoded OCSPRequest ``` I assume the use of `http` instead of `https` is intentional, I wouldn't mind a brief comment on why not HTTPs here. # 8.5. Modification of HTTP Headers is ok? ``` 734 manipulated by an attacker. Clients SHOULD use these values for 735 caching guidance only and ultimately SHOULD rely only on the values 736 present in the signed OCSPResponse. Clients SHOULD NOT rely on ``` Why not MUST? ## Nits ### Section 8.3 capitalize must ``` 715 As detailed in [RFC6960], clients must properly validate the 716 signature of the OCSP response and the signature on the OCSP response 717 signer certificate to ensure an authorized responder created it. ``` ### 8.4. Denial-of-Service Attacks Consider alternative language to "should", such as "ought to", or capitalize it, and make it more actionable. ### Section 3.1.1 DN expand on first use ``` 221 The CertID.issuerNameHash and CertID.issuerKeyHash fields contain 222 hashes of the issuer's DN and public key, respectively. OCSP clients ```
Thanks for working on this update. One thing the I noticed that the profile transport uses HTTP only ( and not HTTPs). There might be good reasons for using it that way in certain scenarios. I would strongly suggest to explain the rational(s) behind the choice.
# Éric Vyncke, INT AD, comments for draft-ietf-lamps-rfc5019bis-08 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (including a nearly DISCUSS for section 3.1.1) but replies would be appreciated even if only for my own education). Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 3.1.1 Even if 3.1.1 is included in 3.1 (profile-related), `OCSPRequests that conform to this profile` the "this" is a little unclear. Suggest to be more specific rather than using "this". About `these OCSP clients should transition`, should this be a normative "SHOULD" ? Also, the paragraph above has a "MUST" for SHA-256 and this text appears to allow for SHA-1. To be honest, I was really close to ballot a DISCUSS on this point. ## Section 3.1.2 I am confused after reading this section. Should the responders simply ignore invalid request signature ? How can a server "MUST be prepared" while still responders "MAY ignore the signature". ## Section 3.2.2 Isn't `on the returned OCSPResponse` a pleonasm ? I.e., the response is always 'returned'. ## Section 3.2.4 `producedAt MUST be expressed Greenwich Mean Time (Zulu)` or should be UTC ? ## Section 6 Even if the payload is signed and contains public information, is a non-https scheme suitable in `including the scheme and delimiters (http://)` ? ## Section 7.1 Should there be any recommendation on the Max-Age value in `responders MAY indicate when the client should fetch an updated OCSP response by using the cache- control:max-age directive`? ## Section 7.2 Are CDN implicitly covered by "HTTP proxies" ? In `max-age = < n > -where n is a time value later than thisUpdate but earlier than nextUpdate.` is max-age really an absolute time rather than a relative time in seconds ? ## Section 7.3 Probably due to my lack of knowledge about OCSP, but is there a difference in "OCSP responder" and "server" in this section ? Especially about `First, it allows for the caching of OCSP responses on the server, thus lowering the number of hits to the OCSP responder.`