> On Apr 15, 2018, at 17:45, Jim Schaad <ietf@xxxxxxxxxxxxxxxxx> wrote: >> -----Original Message----- >> From: Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx> >> Sent: Sunday, April 15, 2018 8:32 AM >> To: ietf@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx> >> Cc: draft-ietf-lamps-rfc5751-bis@xxxxxxxx; lamps-chairs@xxxxxxxx; >> ekr@xxxxxxxx; housley@xxxxxxxxxxxx; spasm@xxxxxxxx >> Subject: RE: [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 >> >> 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" ? > > At the time this document cleared WGLC the answer was definitely no. For > those people who believe in having consistency in all of the hash algorithms > the answer would still be no as there are no SHA-3 signature algorithms that > are currently either MUST or SHOULDs. The answer would be different if > Ed448 was in that list. > > I think that this means the answer is still no. +1 >> 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. :). Yeah not my best weasel words. > This should have been caught and updated when the security considerations > text was updated to address the same problem. > > I have modified my copy to read > > Algorithms such as RC2 are considered to be weak encryption > algorithms. > Algorithms such as TripleDES are not state of the art and > are considered to be weaker algorithms than AES. > A sending agent that is controlled by a human SHOULD > allow a human sender to determine the risks of sending data > using a > weaker encryption algorithm before sending the data, and > possibly allow > the human to use a stronger encryption algorithm such as AES > GCM or AES CBC even if there is a possibility > that the recipient will not be able to process that algorithm. lgtm > Jim > > >> >> -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 >
