I just read the whole draft and have the following comments. Overall, the draft seems to be in excellent shape. I apologize if any of these were discussed earlier in the process, before I started following this draft. More than happy to create a pull request with the changes once I get some feedback on these. Section 2.1: Is it worth adding "SHOULD support SHA-3" ? Section 2.2: "NIST is unable to provide the seeds that were used to create their standardized curves, this means that there is a section of the community which believes that there might be a back door to these curves." This is a comma splice; recommend changing the comma to semi-colon. "there is only a requirement for curve in the sending agent list" I think "only a requirement for ONE curve in the sending agent list" was meant. Section 2.7.2. "All algorithms that use 112-bit keys are considered by many to be weak encryption." Is the LENGTH of the key, or the STRENGTH of the key intended? If the former, are there other examples of 112-bit keys other than two key 3DES (~80 bits of strength)? If not, why not say two key 3DES to be explicit? If the latter, what's the rationale for considering 112 bits of strength weak for symmetric algorithms in a standard where RSA-2048 is considered strong? I don't find "considered by many" to be a useful statement. After all, the world is considered by many to be flat. -Tim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@xxxxxxxx] On Behalf Of The IESG > Sent: Friday, April 13, 2018 5:21 PM > To: IETF-Announce <ietf-announce@xxxxxxxx> > Cc: draft-ietf-lamps-rfc5751-bis@xxxxxxxx; lamps-chairs@xxxxxxxx; > ekr@xxxxxxxx; housley@xxxxxxxxxxxx; spasm@xxxxxxxx > Subject: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt> > (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message > Specification) to Proposed Standard > > > The IESG has received a request from the Limited Additional Mechanisms for > PKIX and SMIME WG (lamps) to consider the following document: - > 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 > Message Specification' > <draft-ietf-lamps-rfc5751-bis-07.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2018-04-27. Exceptionally, comments may be sent > to iesg@xxxxxxxx instead. In either case, please retain the beginning of the > Subject line to allow automated sorting. > > Abstract > > > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used to > reduce data size. This document obsoletes RFC 5751. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > _______________________________________________ > Spasm mailing list > Spasm@xxxxxxxx > https://www.ietf.org/mailman/listinfo/spasm
<<attachment: smime.p7s>>
