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