> -----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.
>
> 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.
Yes this is what should have been there.
>
> 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.
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.
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
