Subject: Re: draft-ietf-smime-cms-rsa-kem-10 LC comments

From: Sean Turner <[email-masked]>
Date: Tue, 16 Feb 2010 11:32:00 -0500

Alfred,

I didn't forget about these.  Responses inline.

spt

Alfred � wrote:
> I have taken a closer look at draft-ietf-smime-cms-rsa-kem-10
> and will send another detailed editorial review to the authors.
> 
> Below are my more significant comments and questions:
> 
> (A)
> 
> Shouldn't this memo be updated to also encompass usage of
> "AES Key Wrap with Padding" (RFC 5649) ?
> (Compared to immediate inclusion in this memo, having to process
> another document performing such update in the near future seems
> to be an undue load on IETF/IESG/RFC-Editor cycles.)
> 
> Otherwise, a short note would be welcome in the memo indicating
> why that is not being done.

To maintain alignment with ANS X9.44 and ISO/IEC 18033-2, I think we're
going to have add a note indicating AES Key Wrap With Padding will be
added to an update of this document when ANSI/ISO/IEC also add it to
their spec.  The work a little slower than the IETF so while it might
add more cycles I'm pretty sure it's not going to happen in the next
year or two.  The suggested note is as follows:

NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding
[AES-WRAP-PAD] in to ANS X9.44. When ASC X9.44 adds AES Key Wrap with
Padding, this document will also be updated.

> (B)
> 
> In Appendix B.1, it is rather confusing (and might most likely
> become the origin of implementation faults) that the draft uses
> the same Name, "RSA-KEM", for the Key Transport Algorithm and the
> underlying KeyEncapsulationMechanism, with the respective OIDs
> named 'id-rsa-kem' and 'id-kem-rsa'.
> 
> The "S/MIME New ASN.1" draft has tried to introduce more rational
> and systematic names for algorithm objects and OIDs, by always
> including an algorithm type specific name component;
> this is "kta-" for key transport algorithms.
> 
> So it might make sense to rename 'id-rsa-kem' to 'id-kta-rsa-kem'
> in order to get a greater "mnemonic distance" from 'id-kem-rsa',
> which is expected to appear in the PARAMETERS of the former.
> 
> Of course, such change needs to be reflected in the ASN.1 module
> in Appendix B.3.

This does make sense and in a perfect world I'd do it, but getting both
ANSI and ISO/IEC to change at the same time is extremely hard.  I'm not
sure it's worth the effort because it could take a very long time to fix
two already published documents.  I think we should let this one go.

> (C)
> 
> In Appendix B.2.1, 'x9-44-components' is used without definition.
> (This definition only appears much later, in the ASN.1 module in B.3.)
> Similar branch OIDs used throughout B.1 and B.2 are collected and
> presented at the beginning of App. B.; therefore, it would make much
> sense to also place there the definition of 'x9-44-components'.

Added.

> (D)
> 
> Appendix B.2.2 still contains the clause written many years ago (it
> appears for the first time in the -01 draft version dated Oct. 2003):
> 
>            vvvvvvvvvvvvvvvvvv
> |    NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key
> |    Wrap are in the process of being approved by ASC X9.
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> It seems likely that this has been resolved in the meantime.
> Please check and correct if necessary.

Modified the note.  See response to (A).

> Kind regards,
>   Alfred H�nes.