Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03

[Russ Housley <[e-mail]>]

i want to confirm that version -04 resolves all of my comments, except one.  That one is being discussed on the thread that Jim started yesterday.

Russ


> On Mar 10, 2017, at 9:48 AM, Russ Housley <[e-mail]> wrote:
> 
> 
>>> I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03.  I
>>> have divided my comments into MAJOR and MINOR.
>>> 
>>> 
>>> MAJOR
>>> 
>>> Do we need to define a way for smimeCapabilities to state support for
>>> AuthEnveloped?  I’m trying to avoid interoperability failures.
>> 
>> We have that.  If you support an AEAD algorithm then you must support AuthEnveloped by definition.
> 
> Sure.  I think the document needs to be explicit on this point.
> 
>>> Section 2.1: I see no need to include the MUST for SHA-512 here since none
>>> of the algorithms in Section 2.2 use it.
>> 
>> This is to get a match for EdDSA w/ curve 25519.  That uses SHA-512 internally so that the correct match would be to use SHA-512 for the external as well.
> 
> Okay.  This one is resolved.
> 
>>> Section 2.7.1.2: I worry about backward compatibility here.  This requires a
>>> capability that has never been used in S/MIME before, so it seems premature
>>> to use AES-GCM when the capabilities of the recipient are unknown.  Instead,
>>> I would argue that AES-256 CBC offers implementers so time to deploy
>>> authenticated encryption.  This looks like a fine thing for S/MIME 4.1 in a
>>> couple of years.
>> 
>> This has been the traditional wording over the last three versions of the document.  Only for 3851 was it clear that the algorithm existed as a possibility prior to the version being released.  The group has normally recommended using the best algorithm here but permitted to use of a different algorithm.  I think there is sufficient guidance in the text about why GCM was chosen and it allows for either it or AES-128 CBC to be used.
> 
> Since a new content type is involved, not just a new algorithm, I am advocating a slower transition.  I’d love to hear from others.  Am I being too conservative?
> 
>>> Section 5.1: The S/MIME WG is closed.  Would it be better to change the
>>> contact to the IESG?
>> 
>> I thought about this and did not do it, but yes it makes sense.   I wonder how many people have used the contact, but as I am not on this alias I would not know. 
> 
> Let’ make it the IESG.
> 
> Russ
>