Ballot for draft-ietf-stir-certificates-ocsp
Yes
No Objection
No Record
Summary: Needs one more YES or NO OBJECTION position to pass.
update: Thank you for addressing my discuss by removing the nonce options from the examples in the appendix. 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.
# É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.
Thanks for addressing my DISCUSS