Scott Thank you for your review and your comments. I am sorry for responding so late. The co-authors and I wanted to consolidate the feedback to the different reviews. Please see my responses to your comments inline below. The latest version of the draft ready for submission and a diff to the latest version on datatracker are available on github: - https://lamps-wg.github.io/cmp-updates/#go.draft-ietf-lamps-rfc4210bis.html - https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc4210bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc4210bis.txt Please let me know if the proposed changes sufficiently address your comments. Hendrik > Von: Scott Kelly via Datatracker <noreply@xxxxxxxx> > Gesendet: Montag, 28. Oktober 2024 00:15 > > Reviewer: Scott Kelly > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call comments. > > The summary of the review is ready. > > From the abstract, this document obsoletes RFC 4210 by including the updates > specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining > backward compatibility with CMP version 2 wherever possible and obsoletes both > documents. > > Because this document is the product a security area working group, I assume the > security considerations have been extensively reviewed already and that this secdir > review is largely pro forma. [HB] I apdated the Apstract to mak it clearer. OLD This document obsoletes RFC 4210 by including the updates specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. Updates to CMP version 2 are: improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. Introducing CMP version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue, hashAlg for indicating a hash AlgorithmIdentifier in certConf messages, and RootCaKeyUpdateContent in ckuann messages. In addition to the changes specified in CMP Updates RFC 9480 this document adds support for management of KEM certificates. Appendix F of this document updates the 2002 ASN.1 module in RFC 5912 Section 9. NEW This document adds support for management of KEM certificates and use EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. The updates maintain backward compatibility with CMP version 2 wherever possible. Updates to CMP version 2 are improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. CMP version 3 is introduced for changes to the ASN.1 syntax, which are support of EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann messages. This document obsoletes RFC 4210 and together with I-D.ietf-lamps-rfc6712bis and it also obsoletes RFC 9480. Appendix F of this document updates the Section 9 of RFC 5912. > > I confirmed that the security considerations section consolidates the security > considerations from RFC4210 and RFC9480. There is one new section added: "8.1. > On the Necessity of Proof-Of-Possession". I think the RFC editor may suggest an > update, but I'll comment anyway - the second sentence says, "If an entity holding a > private key obtains a certificate containing the corresponding public key issued for a > different entity, can authenticate as the entity named in the certificate." I think this > might read more smoothly if you add "it" before "can authenticate". [HB] Thank you for this proposal. I implemented it. > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
