draft-ietf-smime-cms-rsa-kem-10 LC comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

(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.

(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'.

(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.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@xxxxxxxxx                     |
+------------------------+--------------------------------------------+

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]