The IESG has approved the following document: - 'Algorithms for Asymmetric Key Package Content Type ' <draft-turner-asymmetrickeyformat-algs-01.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-asymmetrickeyformat-algs-01.txt Technical Summary This document specifies algorithms to secure the asymmetric key content type defined in draft-turner-asymmetrickeyformat-03.txt. The algorithm choices and key sizes are based on RFC 5751, with the exception of content encryption algorithm and key wrap algorithm being AES Key Wrap with Padding. This rationale for the choice is in the security considerations. This document is headed for standards track, but there are normative references to three informative RFCs. RFC2898 "Password Based Encryption based on PKCS#5" and RFC5649 "AES Key Wrap with Padding" wree called out in this Last Call; RFC3394 "AES Key Wrap" was added to the downref registry earlier in 2010. Working Group Summary This document is not the product of an IETF Working Group. Document Quality The document is short and lists the algorithms to be used based on the encapsulation mechanism. Personnel Carl Wallace is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note 1) Section 1 OLD: keys be managed NEW: keys to be managed 2) Replace the text in Section 2 as follows: OLD The de facto standard used to encrypt the PrivateKeyInfo structure, which is subsequently placed in the EncryptedPrivateKeyInfo encryptedData field, is Password Based Encryption (PBE) based on PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS #5 and PKCS #12 is the supported encoding for the password: ASCII for PKCS #5 and Unicode for PKCS #12. [RFC2898] specifies two PBE Schemes (PBES) 1 and 2, the defacto is PBES 1. The notation for the PBES 1 is: PBEWith<digest>And<encryption>. The following schemes are defined in PKCS #5: PBEWithMD2AndDES-CBC, PBEWithMD2AndRC2, PBEWithMD5AndDES-CBC, PBEWithMD5AndRC2, PBEWithSHA1AndDES-CBC, PBEWithSHA1AndRC2. The following schemes are defined in PKCS #12: PBEWithSHAAnd3-KeyTripleDES-CBC, PBEWithSHAAnd2-KeyTripleDES-CBC, PBEWithSHAAnd128BitRC2-CBC, PBEWithSHAAnd40BitRC2-CBC, PBEWithSHAAnd128BitRC4, and PBEWithSHAAnd40BitRC4. Implementation defaults vary. The PBES 1 algorithms require salt and iteration count values. The salt length in PKCS #5 is 8 octets while there is no restriction on the length of the salt in PKCS #12, but PKCS #12 recommends the salt be as long as the digest algorithms output (e.g., 20 octets for SHA- 1). The iteration count in PKCS #5 is recommended to be at least 1000 and PKCS #12 recommends at least 1024. It is RECOMMENDED that implementations support AES-128 Key Wrap with Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649]. NEW The de facto standard used to encrypt the PrivateKeyInfo structure, which is subsequently placed in the EncryptedPrivateKeyInfo encryptedData field, is Password Based Encryption (PBE) based on PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS #5 and PKCS #12 is the supported encoding for the password: ASCII for PKCS #5 and Unicode for PKCS #12, encoded as specified in Section B.1 of [P12]. [RFC2898] specifies two PBE Schemes (PBES) 1 and 2; [RFC2898] recommends PBESS 2 for new specification. PBES2 with a key derivation algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an encryption algorithm of DES-EDE2-CBC-Pad as defined in [RFC2898] MUST be supported. It is RECOMMENDED that implementations support AES-128 Key Wrap with Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649] as an encryption algorithm. 3) Section 3.2 OLD: If an implementation supports EnvelopedData, then it MUST implement the key transport and it MAY implement the key agreement mechanism. NEW: If an implementation supports EnvelopedData, then it MUST implement key transport and it MAY implement key agreement. 4) Section 6 OLD: The security considerations from [RFC3370], [RFC3394], [RFC3560], [RFC5652], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], [RFC5754], and [RFCTBD1] apply. NEW: The security considerations from [RFC3370], [RFC3560], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5754], and [RFCTBD1] apply. 5) Section 6 OLD: Unfortunately, there is no AES-CCM or AES-GCM mode that provides the same properties. If an AES-CCM and AES-GCM mode that provides the same properties is defined, then this document will be updated to adopt that algorithm. NEW: Unfortunately, there is no AES-GCM or AES-CCM mode that provides the same properties. If an AES-GCM and AES-CCM mode that provides the same properties is defined, then this document will be updated to adopt that algorithm. 6) Section 8.1 Delete reference to [RFC3394]. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
