Ballot for draft-ietf-stir-certificates-ocsp
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
I don't believe this is hard to fix.... General: I see no discussion in the main body of the specification about the use of a nonce to guarantee freshness (there are, however, nonces in the Appendix B examples). Is this intentional? Do you expect that an OCSP responder would generate OCSP proofs in advance (making the nonce option impossible)? In my opinion only, the removal of the nonce option makes it easier to pre generate OCSP proofs that allow quicker distribution in fewer round trips (this eases the ability to staple OCSP). I would recommend making a statement of expectation with regard to the use/non-use of a nonce to guarantee freshness.
Thanks to PHB for their secdir reviews. Section 3, para 3: CRL partitions are mentioned without definition. The previous sentences discuss scoping mechanisms, perhaps add that these scoping mechanisms result in multiple sections of CRLs that are called partitions. Section 8, para 2: Request/Distribution of an OCSP staple is also subject to DNS attacks. An effective mitigation for the denial of service issue is to have OCSP proofs generated in advance, and load balanced, or stored in multiple locations.
I also have what I think is a minor issue to address. Normally with OCSP, there is a concept of "hard fail" vs "soft fail", as the action for what to do when one fails to reach the OCSP server (or fails to update a staple entry). It is unclear to me what the expected behaviour is in this ecosystem, when the OCSP has been unavailable for such a time that pregenerated staples have expired. Does one just omit the OCSP staple and let the requester judge the lack of staple? Does one refuse the call? Mark it has "potential spam" ? How is one client expected to respond when it sees no OCSP staple? Would it attempt to connect to the OCSP server's Distribution Point itself? What if that fails? Would a client treat a response differently if it used to get OCSP information from a server, but suddenly doesn't, versus a server that has never sent OCSP staples. Perhaps a short paragraph in the Security Considerations Section could clarify this.
# Éric Vyncke INT AD comments for draft-ietf-stir-certificates-ocsp-12 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## COMMENTS (non-blocking) ### Spell checker Please use a spell checker, e.g., `Certififcate` in the abstract ;-) ### Section 4.1 Why not a MUST in `Servers SHOULD return responses that would otherwise have been "unknown" as "not good" (i.e., return only "good" and "not good" responses).` especially as the "i.e.," part seems to be mandatory.
It would be good to fix the spelling of "Certififcate" in the abstract!
Thanks to the authors and the WG for their work on this document. I have a few comments to share and hope it improves the document. 1) Abstract: s/Certififcate Revocation Lists/Certificate Revocation Lists 2) section 1: Perhaps s/implementation of credentials which identify the parties/implementation of credentials that identify the parties 3) section 3.5: s/OCSP may provide an important optimizations/OCSP may provide important optimizations 4) Appendix C: s/decorated URI could could then verify/decorated URI could then verify 5) Appendix C: the reference to RFC6961 seems not required since it was obsoleted by RFC8446 which is being obsoleted by RFC8446bis that is being referenced right next to RFC6961 ?
Hi Jon and Sean, Thank you for the effort put in this document. I find the problem well described. I trust the ASN module and examples were validated. Please find below few easy-to-fix comments: # RECOMMENDS is not a BCP 14 key word CURRENT: Between the OCSP and SCVP, OCSP is much more widely deployed and this document therefore RECOMMENDS the use of OCSP in high-volume environments (HVE) for validating the freshness of telephone-number based certificates, based on [RFC6960], incorporating some (but not all) of the optimizations of [RFC5019]. Please fix that. # Which one is the valid module name? CURRENT: This document makes use of object identifiers for the TN-HVE OCSP extension in Section 4.1 and the ASN.1 module identifier defined in Appendix A. It therefore requests that the IANA make the following assignments: TN-OCSP-Module-2016 OID in the SMI Security for PKIX Module Identifier registry: https://www.iana.org/assignments/smi-numbers/ smi- numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 Vs. Appendix A. ASN.1 Module … TN-OCSP-Module-2023 { iso(1) identified-organization(3) dod(6) internet(1) # Is there any expected IANA action for id-mod-tn-ocsp-module-2023(TBD)? CURRENT: TN-OCSP-Module-2023 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tn-ocsp-module-2023(TBD) } Cheers, Med
Thank you to Vijay Gurbani for the GENART review.