Robert: > Reviewer: Robert Sparks > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lamps-cms-mix-with-psk-05 > Reviewer: Robert Sparks > Review Date: 2019-07-30 > IETF LC End Date: 2019-08-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: Essentially ready for publication as a Proposed Standard, but with an > issue to address before publication. > > Issue: The instructions for IANA are unclear. IANA has to infer what to add to > the registries. I think they _can_ infer what to do for the IANA-MOD registry. > It's harder (though still possible) to guess what to do for IANA-SMIME. They > also have to infer the structure of the new registry this document intends to > create. Explicit would be better. Also, the document anticipates the currently > non-existing anchor to the new registry in the references (security-smime-13). > That generally should also be a tbd to be filled by IANA when the anchor is > actually created. Based on the summary of actions that IANA produced during Last Call, they understood the current text. That said, I will try to be more clear. One object identifier for the ASN.1 module in the Section 5 was assigned in the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0) TBD0 } One new registry was created for Other Recipient Info Identifiers within the SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16) [IANA-SMIME] registry: id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } Two assignments were made in the new SMI Security for Other Recipient Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with references to this document: id-ori-keyTransPSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 1 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 2 } I have changed the reference to #security-smime-TBD1, which matches the to-be-assigned value in the IANA Considerations. > Nits/editorial comments: > > Section 5, 1st paragraph, last sentence: "make use fo" should be "makes use of" Yes. That was caught by another review. Already corrected. > Section 9, 1st sentence : "in the Section 5" should be "in Section 6". (That's > two changes - the removal of a word, and a correction to the section number). Good catch. Fixed. > Micronit: In the introduction, you say "can be invulnerable to an attacker". > "invulnerable" is maybe stronger than you mean? Roman thought that was too strong as well, I suggest: ... In this way, today's CMS-protected communication can be resistant to an attacker with a large-scale quantum computer. Thanks for the vaery careful reading, Russ
