Re: [lamps] Genart last call review of draft-ietf-lamps-cms-mix-with-psk-05

[Russ Housley <[e-mail]>]

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