[lamps] Robert Wilton's Yes on draft-ietf-lamps-e2e-mail-guidance-15: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-lamps-e2e-mail-guidance-15: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document. I'm no expert on the email related RFCs but I found
this document to be very well written, being both easy to read and understand.

I was considering balloting 'DISCUSS' on this document because I think that it
should really be a BCP rather than Informational.  Was BCP considered (the
shepherd writeup doesn't indicate) and dismissed?

Anyway, I have a few other minor/nit level comments for the authors
consideration:

Minor level comments:

(1) p 14, sec 4.1.1.4.  S/MIME PKCS7 authEnveloped-data Cryptographic Layer

   Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
   (Section 4.1.1.4) have identical message structure and very similar
   semantics.  The only difference between the two is ciphertext
   malleability.

I was slightly confused by the statement that they offer very similar semantics
when one of them offers integrity and the other does not, at least according to
the explanations accompanying them.

(2) p 26, sec 6.4.  Signature failures

   A conformant MUA MUST NOT render a message with a failed signature as
   more dangerous or more dubious than a comparable message without any
   signature at all.  In both cases, the Cryptographic Summary should be
   Unprotected.

Does it still make sense to flag the failed signature at all, e.g., so
potentially the receiver can warn the sender that their signature is failing?

Nit level comments:

(3) p 30, sec 7.3.  MIME Part Examples

   In this case, parts M and N are still the Cryptographic Envelope.

are still => are still in?

(4) p 31, sec 8.1.1.  Peer Certificate Selection

   *  It must have a subjectAltName of type rfc822Name whose contents
      match the destination address.  In particular, the local-part of
      the two addresses should be an exact bytewise match, and the
      domain parts of the two addresses should be matched by ensuring
      label equivalence across the full domain name, as described in
      Section 2.3.2.4 of [RFC5890].

For clarity, perhaps "destination address" => "destination e-mail address".

Regards,
Rob