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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
