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.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf