Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
RFC 5990
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
13 | (System) | Notify list changed from smime-chairs@ietf.org, draft-ietf-smime-cms-rsa-kem@ietf.org to (None) |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2010-09-23
|
13 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue by Cindy Morgan |
2010-09-23
|
13 | Cindy Morgan | [Note]: changed to 'RFC 5990' by Cindy Morgan |
2010-09-23
|
13 | (System) | RFC published |
2010-06-11
|
13 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2010-06-10
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2010-06-10
|
13 | (System) | IANA Action state changed to In Progress |
2010-06-10
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2010-06-10
|
13 | Cindy Morgan | IESG has approved the document |
2010-06-10
|
13 | Cindy Morgan | Closed "Approve" ballot |
2010-06-08
|
13 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-06-08
|
13 | Peter Saint-Andre | [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"). … [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)? |
2010-06-07
|
13 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2010-06-01
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-06-01
|
13 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-13.txt |
2010-05-29
|
13 | Sean Turner | [Ballot Position Update] New position, Recuse, has been recorded by Sean Turner |
2010-03-31
|
13 | Russ Housley | [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 … [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. |
2010-03-31
|
13 | Russ Housley | [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: - … [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. |
2010-03-12
|
13 | (System) | Removed from agenda for telechat - 2010-03-11 |
2010-03-11
|
13 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-03-11
|
13 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2010-03-11
|
13 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-03-11
|
13 | Amy Vezza | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza |
2010-03-11
|
13 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-03-11
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2010-03-11
|
13 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2010-03-11
|
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-03-10
|
13 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2010-03-10
|
13 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-03-10
|
13 | Cullen Jennings | [Ballot comment] Thanks for the examples in the back. I know they helped at least one implementor. |
2010-03-10
|
13 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings |
2010-03-10
|
13 | Pasi Eronen | [Ballot comment] Typo: A.2, "public key n,e)" -> "public key (n,e)" |
2010-03-10
|
13 | Pasi Eronen | [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: - … [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. |
2010-03-10
|
13 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2010-03-10
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-03-09
|
13 | Russ Housley | [Ballot comment] |
2010-03-09
|
13 | Russ Housley | [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 … [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. |
2010-03-09
|
13 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes by Russ Housley |
2010-03-09
|
13 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2010-03-09
|
13 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley |
2010-03-09
|
13 | Lars Eggert | [Ballot discuss] Sorry for playing downref police. Section 6.1., paragraph 1: > [3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC > … [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. |
2010-03-09
|
13 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2010-03-08
|
12 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-12.txt |
2010-03-08
|
13 | Russ Housley | [Ballot comment] Section 2 says: > > The RSA-KEM Key Transport Algorithm SHOULD be considered for new CMS- > based applications as … [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. |
2010-03-08
|
13 | Russ Housley | [Ballot discuss] Section 2.1 says: > > The Camellia key wrap algorithm (see [CAMELLIA]) SHOULD be > supported, and, if 3DES is … [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/ |
2010-03-08
|
13 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2010-03-08
|
13 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-02-25
|
13 | Cindy Morgan | Last call sent |
2010-02-25
|
13 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2010-02-25
|
13 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
2010-02-25
|
13 | Tim Polk | Ballot has been issued by Tim Polk |
2010-02-25
|
13 | Tim Polk | Created "Approve" ballot |
2010-02-25
|
13 | Tim Polk | State Changes to Last Call Requested from Waiting for AD Go-Ahead by Tim Polk |
2010-02-25
|
13 | Tim Polk | Last Call was requested by Tim Polk |
2010-02-23
|
13 | Tim Polk | Placed on agenda for telechat - 2010-03-11 by Tim Polk |
2010-02-19
|
11 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-11.txt |
2010-01-07
|
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-12-18
|
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Kent. |
2009-12-18
|
13 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-12-11
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2009-12-11
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2009-12-10
|
13 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-12-10
|
13 | Tim Polk | Last Call was requested by Tim Polk |
2009-12-10
|
13 | Tim Polk | State Changes to Last Call Requested from Publication Requested by Tim Polk |
2009-12-10
|
13 | Cindy Morgan | State Changes to Publication Requested from Waiting for AD Go-Ahead::AD Followup by Cindy Morgan |
2009-12-10
|
13 | Cindy Morgan | 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 … 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. |
2009-12-08
|
10 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-10.txt |
2009-12-08
|
09 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-09.txt |
2009-12-07
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-12-07
|
08 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-08.txt |
2009-07-29
|
13 | Tim Polk | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup by Tim Polk |
2009-07-07
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-07-07
|
07 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-07.txt |
2009-07-06
|
13 | Tim Polk | Changed proto shepherd, as previous shepherd (Sean Turner) is now co-authoring. |
2009-07-06
|
13 | Tim Polk | [Note]: 'proto shepherd is Blake Ramsdell <blaker@gmail.com>' added by Tim Polk |
2009-07-06
|
13 | Tim Polk | 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 … 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. |
2009-07-06
|
13 | Tim Polk | [Note]: 'proto shepherd is Sean Turner <turners@ieca.com>' added by Tim Polk |
2009-04-15
|
13 | Tim Polk | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Tim Polk |
2009-04-15
|
13 | Tim Polk | need a revision to address issues raised by Steve Kent |
2008-11-19
|
13 | Tim Polk | Removed from agenda for telechat - 2008-12-11 by Tim Polk |
2008-11-18
|
13 | Tim Polk | Placed on agenda for telechat - 2008-12-11 by Tim Polk |
2008-11-10
|
06 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-06.txt |
2008-07-09
|
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Kent. |
2008-07-04
|
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-06-30
|
13 | Amanda Baber | 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 … 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. |
2008-06-25
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2008-06-25
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2008-06-20
|
13 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-06-20
|
13 | Tim Polk | State Changes to Last Call Requested from Publication Requested::External Party by Tim Polk |
2008-06-20
|
13 | Tim Polk | Last Call was requested by Tim Polk |
2008-06-20
|
13 | (System) | Ballot writeup text was added |
2008-06-20
|
13 | (System) | Last call text was added |
2008-06-20
|
13 | (System) | Ballot approval text was added |
2007-11-06
|
(System) | Posted related IPR disclosure: Sean Turner's Statement about IPR related to draft-ietf-smime-cms-rsa-kem-05 belonging to Various | |
2007-10-22
|
13 | Tim Polk | Needa an IPR disclosure statement. |
2007-10-22
|
13 | Tim Polk | State Changes to Publication Requested::External Party from Publication Requested by Tim Polk |
2007-10-19
|
13 | Tim Polk | Draft Added by Tim Polk in state Publication Requested |
2007-10-19
|
05 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-05.txt |
2007-07-25
|
04 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-04.txt |
2007-05-31
|
03 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-03.txt |
2006-03-23
|
02 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-02.txt |
2003-10-24
|
01 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-01.txt |
2003-05-19
|
00 | (System) | New version available: draft-ietf-smime-cms-rsa-kem-00.txt |