Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
RFC 5990

[Ballot comment]
1. In Section 1, the text "specified the of different object identifier" is missing a word (I assume "use" between "the" and "of").

2. In Section 2.4, this text is potentially confusing:

  The intended application for the key MAY be indicated in the key
  usage certificate extension (see [PROFILE], Section 4.2.1.3). If the
  keyUsage extension is present in a certificate that conveys an RSA
  public key with the id-rsa-kem object identifier as discussed above,
  then the key usage extension MUST contain the following value:

      keyEncipherment.

Is the indented text meant to be "keyEncipherment" (without the period) instead of "keyEncipherment." (with the period)?

[Ballot discuss]
The ASN.1 is not fully aligned with X9.44 (also ISO 18033-2).  X9.44
would use the id-ac-generic-hybrid OID (instead of id-rsa-kem), and
then a parameter would indicate that only KEM should be used with
the certified public key.  The approach in this document does not
require parameter parsing, which seems like a good idea to me.

The Chair of X9F1 has been asked if this will be added to a future
update to X9.44, but he has not responded yet.  It would be very good
for X9.44 and an RFC to suggest the same solution going forward.

Section 2.1, "KDF3 (see [IEEE-P1363a])": IEEE 1363a-2004 does not
have KDF3; it does, however, define KDF2. Should this be KDF2, or
should the reference point to X9.44?

It looks like ANS X9.44 needs to be a normative, unless the KDF can be
found some other place.

[Ballot discuss]
I have reviewed draft-ietf-smime-cms-rsa-kem-12, and have couple of
small concern that I'd like to discuss before recommending approval of
the document:

- It looks like the ASN.1 is not fully aligned with 18033-2 and X9.44.
I might be misinterpreting this, but to me it looks like 18033-2 and
X9.44 would use OID "id-ac-generic-hybrid" (instead of id-rsa-kem) as
the "top-level OID", and id-kem-rsa would be found in
GenericHybridParameters.kem structure.

The OID id-rsa-kem is not used in X9.44.  The Chair of X9F1 has been
asked if this will be added to a future update to X9.44, but he has
not responded yet.  It would be bad for X9.44 and an RFC to suggest
different aand incompatible solutions.

Section 2.1, "KDF3 (see [IEEE-P1363a])": IEEE 1363a-2004 does not
have KDF3; it does, however, define KDF2. Should this be KDF2, or
should the reference point to X9.44?

It looks like ANS X9.44 needs to be a normative, unless the KDF can be
found some other place.

[Ballot discuss]
I have reviewed draft-ietf-smime-cms-rsa-kem-12, and have couple of
small concern that I'd like to discuss before recommending approval of
the document:

- It looks like the ASN.1 is not fully aligned with 18033-2 and X9.44.
I might be misinterpreting this, but to me it looks like 18033-2 and
X9.44 would use OID "id-ac-generic-hybrid" (instead of id-rsa-kem) as
the "top-level OID", and id-kem-rsa would be found in
GenericHybridParameters.kem structure.

(The OID id-rsa-kem doesn't seem to occur in 18033-2/X9.44 at all?
And BTW, it's *very* confusing to have two different OIDs named
id-rsa-kem and id-kem-rsa.)

- Section 2.1, "KDF3 (see [IEEE-P1363a])": IEEE 1363a-2004 doesn't
have KDF3; it does, however, define KDF2. Should this be KDF2, or
should the reference point to X9.44?

- It looks like ANS-9.44 needs to be normative references, since you
need the KDF to implement this.

[Ballot discuss]
The second Last Call expires 2010-03-11. The IESG should not declare
  that the downrefs called out in that Last Call are acceptiable to the
  community until the Last Call is actually over.  I do not expect any
  objection, but let's not jump the gun.

[Ballot discuss]
Sorry for playing downref police.

Section 6.1., paragraph 1:
>    [3DES-WRAP]      Housley, R. Triple-DES and RC2 Key Wrapping. RFC
>                      3217. December 2001.

  DISCUSS: Downref: Normative reference to an Informational RFC: RFC
  3217 (ref. '3DES-WRAP'). Last-call didn't mention.


Section 6.1., paragraph 2:
>    [AES-WRAP]        Schaad, J. and R. Housley. Advanced Encryption
>                      Standard (AES) Key Wrap Algorithm. RFC 3394.
>                      September 2002.

  DISCUSS:  Downref: Normative reference to an Informational RFC: RFC
  3394 (ref. 'AES-WRAP'). Last-call didn't mention.

[Ballot comment]
Section 2 says:
  >
  > The RSA-KEM Key Transport Algorithm SHOULD be considered for new CMS-
  > based applications as a replacement for the widely implemented RSA
  > encryption algorithm specified originally in PKCS #1 v1.5 (see
  > [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to
  > chosen-ciphertext attacks.
  >
  s/SHOULD/should/  (this is not a statement about the protocol)
  Also, I think the discussion of attacks and security proofs in this
  section are better located in the Security Considerations.  There is
  already some discussion there, and these statements would be a good
  introduction to them.

[Ballot discuss]
Section 2.1 says:
  >
  > The Camellia key wrap algorithm (see [CAMELLIA]) SHOULD be
  > supported, and, if 3DES is supported as a content-encryption cipher,
  > then the Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be
  > supported.
  >
  This should be broken into two statements:
  (1) The Camellia key wrap algorithm (see [CAMELLIA]) SHOULD be
      supported if Camellia is supported as a content-encryption
      cipher.
  (2) The Triple-DES Key Wrap algorithm (see [3DES-WRAP]) SHOULD be
      supported if Triple-DES is supported as a content-encryption
      cipher.

  Section 2.3 says:
  >
  > If the recipient wishes only to employ the RSA-KEM Key Transport
  > Algorithm with a given public key, the recipient MUST identify the
  > public key in the certificate using the id-rsa-kem object identifier
  > (see Appendix B). When the id-kta-rsa-kem algorithm identifier
  > appears in the SubjectPublicKeyInfo algorithm field, the encoding
  > SHALL omit the parameters field from AlgorithmIdentifier. That is,
  > the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the
  > object identifier id-rsa-kem.
  >
  s/id-kta-rsa-kem/id-rsa-kem/

1.a - Blake Ramsdell is the Shepherd. He's personally reviewed the
document and knows it is ready for IESG publication.
1.b - The document has been reviewed by key WG members. There are no
concerns about depth or breadth of the reviews.
1.c - There is no need for wider review.
1.d - There are no specific concerns that the AD and/or IESG should be
aware of.
1.e - The WG consensus is solid.
1.f - There has been no threat of an appeal.
1.g - The Shepherd has personally verified that the document satisfies
all ID nits. There are two normative references to informational RFCs:
RFC 2317 and RFC 3394.
1.h - The document splits it references.
1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).
1.j - The reviewer has personally verified the ASN.1.
1.h - Write-up is as follows:

Technical Summary

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions for
using the RSA-KEM Key Transport Algorithm with the Cryptographic Message
Syntax (CMS).

Working Group Summary

The draft was development in ANSI and ISO/IEC. The CMS part describes
where you put the OIDs is non-controversial. Note that the algorithm in
Appendix A and ASN.1 in Appendix B is aligned with ANS X9.44 and ISO/IEC
18033-2.

This document was scheduled to be on an IESG telechat in 2008-12-11, but
it was sent back to the S/MIME WG after comments were received from
Steve Kent during his SECDIR review on the public key certificate
parameters. This version addresses, Steve's comments as well as other
comments raised by Jim Schaad on the S/MIME mailing list.

Note that there is one remaining OID that to be registered, and this
will occur immediately following IESG approval.

Document Quality

As noted in the draft: The RSA-KEM Key Transport Algorithm in various
forms is being adopted in several draft standards as well as in
ANS-X9.44 and ISO/IEC 18033-2. It has also been recommended by the
NESSIE project [NESSIE].

Personnel

Blake Ramsdell is the document Shepherd. Tim Polk is the responsible
Security Area AD.

Answering questions 1.a-1.h in RFC 4858:

1.a - Sean Turner is the Shepherd.  He's personally reviewed the document
and knows it is ready for IESG publication.
1.b - The document has been reviewed by key WG members.  There are no
concerns about depth or breadth of the reviews.
1.c - There is no need for wider review.
1.d - There are no specific concerns that the AD and/or IESG should be aware
of, but note that the the Shepherd is not a cryptographer.  The Shepherd has
relied on members of the WG, ANSI, and ISO who are cryptographers for
algorithm "correctness."
1.e - The WG consensus is solid as a rock.
1.f - There has been no threat of an appeal.
1.g - The Shepherd has personally verified that the document satisfies all
ID nits.
1.h - The document splits it references.
1.i - The document has an IANA consideration and it is consistent with the
main body (there are no IANA considerations).
1.j - The reviewer has NOT personally verified the ASN.1, but knows Jim S.
has.
1.h - Write-up is as follows:

Technical Summary

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the recipient's
RSA public key. This document specifies the conventions for using the
RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS).

Working Group Summary

The draft was development in ANSI and ISO/IEC.  The CMS part describes where
you put the OIDs is non-controversial.  Note that the algorithm in Appendix
A and ASN.1 in Appendix B is aligned with ANS X9.44 and ISO/IEC 18033-2.

Document Quality

As noted in the draft: The RSA-KEM Key Transport Algorithm in various forms
is being adopted in several draft standards as well as in ANS-X9.44 and
ISO/IEC 18033-2. It has also been recommended by the NESSIE project
[NESSIE].

Personnel

Sean Turner is the document Shepherd.  Tim Polk is the responsible Security
Area AD.

IANA Last Call comments:

QUESTION: You reference an ASN.1 module identifier and point to
section B.3, but we cannot find one that should be or has been
registered by IANA.

We understand that all IANA Actions have already been processed
and that this document has NO NEW IANA Actions.