| < draft-turner-asymmetrickeyformat-algs-00.txt | draft-turner-asymmetrickeyformat-algs-01.txt > | |||
|---|---|---|---|---|
| Network Working Group Sean Turner, IECA | Network Working Group Sean Turner, IECA | |||
| Internet Draft November 9, 2009 | Internet Draft February 1, 2010 | |||
| Intended Status: Standard Track | Intended Status: Standard Track | |||
| Expires: March 9, 2010 | Expires: August 1, 2010 | |||
| Algorithms for Asymmetric Key Package Content Type | Algorithms for Asymmetric Key Package Content Type | |||
| draft-turner-asymmetrickeyformat-algs-00.txt | draft-turner-asymmetrickeyformat-algs-01.txt | |||
| Abstract | ||||
| This document describes the conventions for using several | ||||
| cryptographic algorithms with the EncryptedPrivateKeyInfo structure, | ||||
| as defined in RFC TBD1. It also includes conventions necessary to | ||||
| protect the AsymmetricKeyPackage content type with SignedData, | ||||
| EnvelopedData, EncryptedData, AuthenticatedData, and | ||||
| AuthEnvelopedData. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. This document may contain material | |||
| from IETF Documents or IETF Contributions published or made publicly | from IETF Documents or IETF Contributions published or made publicly | |||
| available before November 10, 2008. The person(s) controlling the | available before November 10, 2008. The person(s) controlling the | |||
| copyright in some of this material may not have granted the IETF | copyright in some of this material may not have granted the IETF | |||
| Trust the right to allow modifications of such material outside the | Trust the right to allow modifications of such material outside the | |||
| IETF Standards Process. Without obtaining an adequate license from | IETF Standards Process. Without obtaining an adequate license from | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 2, line 4 ¶ | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| This Internet-Draft will expire on November 9, 2009. | This Internet-Draft will expire on August 1, 2010. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
| publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | ||||
| Abstract | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | ||||
| This document describes the conventions for using several | described in the Simplified BSD License. | |||
| cryptographic algorithms with the EncryptedPrivateKeyInfo structure, | ||||
| as defined in RFC 5208. It also includes conventions necessary to | ||||
| protect the AsymmetricKeyPackage content type with SignedData, | ||||
| EnvelopedData, EncryptedData, AuthenticatedData, and | ||||
| AuthEnvelopedData. | ||||
| 1. Introduction | 1. Introduction | |||
| This document describes the conventions for using several | This document describes the conventions for using several | |||
| cryptographic algorithms with the EncryptedPrivateKeyInfo structure | cryptographic algorithms with the EncryptedPrivateKeyInfo structure | |||
| [RFC5208]. The EncryptedPrivateKeyInfo is used by [P12] to encrypt | [RFCTBD1]. The EncryptedPrivateKeyInfo is used by [P12] to encrypt | |||
| PrivateKeyInfo [RFCTBD1]. It is similar to EncryptedData [RFC3852] in | PrivateKeyInfo [RFCTBD1]. It is similar to EncryptedData [RFC5652] in | |||
| that it has no recipients, no originators, and no content encryption | that it has no recipients, no originators, and no content encryption | |||
| keys and requires keys be managed by other means. | keys and requires keys be managed by other means. | |||
| This document also includes conventions necessary to protect the | This document also includes conventions necessary to protect the | |||
| AsymmetricKeyPackage content type [RFCTBD1] with Cryptographic | AsymmetricKeyPackage content type [RFCTBD1] with Cryptographic | |||
| Message Syntax (CMS) protecting content types: SignedData [RFC3852], | Message Syntax (CMS) protecting content types: SignedData [RFC5652], | |||
| EnvelopedData [RFC3852], EncryptedData [RFC3852], AuthenticatedData | EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData | |||
| [RFC3852], and AuthEnvelopedData [RFC5083]. Implementations of | [RFC5652], and AuthEnvelopedData [RFC5083]. Implementations of | |||
| AsymmetricKeyPackage do not require support for any CMS protecting | AsymmetricKeyPackage do not require support for any CMS protecting | |||
| content type; however, if the AsymmetricKeyPackage is CMS protected | content type; however, if the AsymmetricKeyPackage is CMS protected | |||
| it is RECOMMENDED that conventions defined herein be followed. | it is RECOMMENDED that conventions defined herein be followed. | |||
| This document does not define any new algorithms instead it refers to | This document does not define any new algorithms instead it refers to | |||
| previously defined algorithms. | previously defined algorithms. | |||
| 1.1. Terminology | 1.1. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| 2. EncryptedPrivateKeyInfo | 2. EncryptedPrivateKeyInfo | |||
| The de facto standard used to encrypt the PrivateKeyInfo structure, | The de facto standard used to encrypt the PrivateKeyInfo structure, | |||
| which is subsequently placed in the EncryptedPrivateKeyInfo | which is subsequently placed in the EncryptedPrivateKeyInfo | |||
| encryptedData field, is Password Based Encryption (PBE) based on | encryptedData field, is Password Based Encryption (PBE) based on | |||
| PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS | PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS | |||
| #5 and PKCS #12 being the supported encoding for the password: ASCII | #5 and PKCS #12 is the supported encoding for the password: ASCII for | |||
| for PKCS #5 and Unicode for PKCS #12. [RFC2898] specifies two | PKCS #5 and Unicode for PKCS #12. [RFC2898] specifies two PBE | |||
| mechanisms PBE Schemes (PBES) 1 and 2, the defacto is PBES 1. The | Schemes (PBES) 1 and 2, the defacto is PBES 1. The notation for the | |||
| notation for the PBES 1 is: PBEWith<digest>And<encryption>. The | PBES 1 is: PBEWith<digest>And<encryption>. The following schemes are | |||
| following schemes are defined in PKCS #5: PBEWithMD2AndDES-CBC, | defined in PKCS #5: PBEWithMD2AndDES-CBC, PBEWithMD2AndRC2, | |||
| PBEWithMD2AndRC2, PBEWithMD5AndDES-CBC, PBEWithMD5AndRC2, | PBEWithMD5AndDES-CBC, PBEWithMD5AndRC2, PBEWithSHA1AndDES-CBC, | |||
| PBEWithSHA1AndDES-CBC, PBEWithSHA1AndRC2. The following schemes are | PBEWithSHA1AndRC2. The following schemes are defined in PKCS #12: | |||
| defined in PKCS #12: PBEWithSHAAnd3-KeyTripleDES-CBC, PBEWithSHAAnd2- | PBEWithSHAAnd3-KeyTripleDES-CBC, PBEWithSHAAnd2-KeyTripleDES-CBC, | |||
| KeyTripleDES-CBC, PBEWithSHAAnd128BitRC2-CBC, PBEWithSHAAnd40BitRC2- | PBEWithSHAAnd128BitRC2-CBC, PBEWithSHAAnd40BitRC2-CBC, | |||
| CBC, PBEWithSHAAnd128BitRC4, and PBEWithSHAAnd40BitRC4. | PBEWithSHAAnd128BitRC4, and PBEWithSHAAnd40BitRC4. Implementation | |||
| Implementation defaults vary. | defaults vary. | |||
| The PBES 1 algorithms require salt and iteration count values. The | 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 | 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 | 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- | 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 | 1). The iteration count in PKCS #5 is recommended to be at least | |||
| 1000 and PKCS #12 recommends at least 1024. | 1000 and PKCS #12 recommends at least 1024. | |||
| It is RECOMMENDED that implementations support AES-128 Key Wrap with | It is RECOMMENDED that implementations support AES-128 Key Wrap with | |||
| Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649]. | Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649]. | |||
| 3. AsymmetricKeyPackage | 3. AsymmetricKeyPackage | |||
| As noted in Asymmetric Key Packages [RFCTBD1], CMS can be used to | As noted in Asymmetric Key Packages [RFCTBD1], CMS can be used to | |||
| protect the AsymmetricKeyPackage. The following provides guidance | protect the AsymmetricKeyPackage. The following provides guidance | |||
| for SignedData [RFC3852], EnvelopedData [RFC3852], EncryptedData | for SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData | |||
| [RFC3852], AuthenticatedData [RFC3852], and AuthEnvelopedData | [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData | |||
| [RFC5083]. | [RFC5083]. | |||
| 3.1. SignedData | 3.1. SignedData | |||
| If an implementation supports SignedData, then it MUST support RSA | If an implementation supports SignedData, then it MUST support the | |||
| [RFC3370], SHOULD support RSASSA-PSS [RFC4056], and SHOULD support | signature scheme RSA [RFC3370] and SHOULD support the signature | |||
| DSA [RFC3370]. Additionally, implementations MUST support SHA-256 | schemes RSASSA-PSS [RFC4056] and DSA [RFC3370]. Additionally, | |||
| [RFCTBD3] and SHOULD support SHA-1 [RFC3370]. | implementations MUST support in concert with these signature schemes | |||
| the hash function SHA-256 [RFC5754] and it SHOULD support the hash | ||||
| function SHA-1 [RFC3370]. | ||||
| 3.2. EnvelopedData | 3.2. EnvelopedData | |||
| If an implementation supports EnvelopedData, then it MUST implement | If an implementation supports EnvelopedData, then it MUST implement | |||
| the key transport and it MAY implement the key agreement mechanism. | the key transport and it MAY implement the key agreement mechanism. | |||
| When key transport is used, RSA encryption [RFC3370] MUST be | When key transport is used, RSA encryption [RFC3370] MUST be | |||
| supported and RSAES-OAEP [RFC3560] SHOULD be supported. | supported and RSAES-OAEP [RFC3560] SHOULD be supported. | |||
| When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370] | When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370] | |||
| SHOULD be supported. | SHOULD be supported. | |||
| Regardless of the key management technique choice, implementations | Regardless of the key management technique choice, implementations | |||
| MUST support AES-128 Key Wrap with Padding [RFC5649]. | MUST support AES-128 Key Wrap with Padding [RFC5649]. | |||
| Implementations SHOULD support AES-256 Key Wrap with Padding | Implementations SHOULD support AES-256 Key Wrap with Padding | |||
| [RFC5649]. | [RFC5649]. | |||
| When key agreement is used, a key wrap algorithm is also specified to | When key agreement is used, a key wrap algorithm is also specified to | |||
| wrap the content encryption key. If the content encryption algorithm | wrap the content encryption key. If the content encryption algorithm | |||
| is AES-128 Key Wrap with Padding, then key wrap algorithm MUST be | is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be | |||
| AES-128 Key Wrap with Padding [RFC5649]. If the content encryption | AES-128 Key Wrap with Padding [RFC5649]. If the content encryption | |||
| algorithm is AES-256 Key Wrap with Padding, then the key wrap | algorithm is AES-256 Key Wrap with Padding, then the key wrap | |||
| algorithm MUST be AES-256 Key Wrap with Padding [RFC5649]. | algorithm MUST be AES-256 Key Wrap with Padding [RFC5649]. | |||
| 3.3. EncryptedData | 3.3. EncryptedData | |||
| If an implementation supports EncryptedData, then it MUST implement | If an implementation supports EncryptedData, then it MUST implement | |||
| AES-128 Key Wrap with Padding [RFC5649] and MAY implement AES-256 Key | AES-128 Key Wrap with Padding [RFC5649] and MAY implement AES-256 Key | |||
| Wrap with Padding [RFC5649]. | Wrap with Padding [RFC5649]. | |||
| NOTE: EncryptedData requires that keys be managed by means other than | NOTE: EncryptedData requires that keys be managed by other means; | |||
| EncryptedData; therefore, the only algorithm specified is the content | therefore, the only algorithm specified is the content encryption | |||
| encryption algorithm. | algorithm. | |||
| 3.4. AuthenticatedData | 3.4. AuthenticatedData | |||
| If an implementation supports AuthenticatedData, then it MUST | If an implementation supports AuthenticatedData, then it MUST | |||
| implement SHA-256 [RFCTBD3] and SHOULD support SHA-1 [RFC3370] as the | implement SHA-256 [RFC5754] and SHOULD support SHA-1 [RFC3370] as the | |||
| message digest algorithm. Additionally, HMAC with SHA-256 [RFC4231] | message digest algorithm. Additionally, HMAC with SHA-256 [RFC4231] | |||
| MUST be supported and HMAC with SHA-1 [RFC3370] SHOULD be supported. | MUST be supported and HMAC with SHA-1 [RFC3370] SHOULD be supported. | |||
| 3.5. AuthEnvelopedData | 3.5. AuthEnvelopedData | |||
| If an implementation supports AuthenticatedData, then it MUST | If an implementation supports AuthEnvelopedData, then it MUST | |||
| implement the EnvelopedData recommendations except for the content | implement the EnvelopedData recommendations except for the content | |||
| encryption algorithm, which in this case is MUST be either 128-bit | encryption algorithm, which in this case MUST be AES-GCM [RFC5084]; | |||
| AES-CCM or AES-GCM [RFC5084] or SHOULD BE 256-bit AES-CCM or AES-GCM | the 128-bit version MUST be implemented and the 256-bit version | |||
| SHOULD be implemented. Implementations MAY also support for AES-CCM | ||||
| [RFC5084]. | [RFC5084]. | |||
| 4. Public Key Sizes | 4. Public Key Sizes | |||
| The easiest way to implement the key transport requirement for | The easiest way to implement the key transport requirement for | |||
| EnvelopedData and AuthenticatedData is with public key certificates | EnvelopedData and AuthenticatedData is with public key certificates | |||
| [RFC5280]. If an implementation support RSA, RSAES-OAEP, or DH, then | [RFC5280]. If an implementation support RSA, RSAES-OAEP, or DH, then | |||
| it MUST support key lengths from 1024-bit to 2048-bit, inclusive. | it MUST support key lengths from 1024-bit to 2048-bit, inclusive. | |||
| 5. SMIMECapabilities Attribute | 5. SMIMECapabilities Attribute | |||
| [RFCTBD4] defines the SMIMECapabilities attribute as a mechanism for | [RFC5751] defines the SMIMECapabilities attribute as a mechanism for | |||
| recipients to indicate their supported capabilities including the | recipients to indicate their supported capabilities including the | |||
| algorithms they support. The following are values for the | algorithms they support. The following are values for the | |||
| SMIMECapabilities attribute for AES Key Wrap with Padding [RFC5649] | SMIMECapabilities attribute for AES Key Wrap with Padding [RFC5649] | |||
| when used as a content encryption algorithm: | when used as a content encryption algorithm: | |||
| AES-128 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 08 | AES-128 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 08 | |||
| AES-192 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 1C | AES-192 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 1C | |||
| AES-256 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 30 | AES-256 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 30 | |||
| 6. Security Considerations | 6. Security Considerations | |||
| The security considerations from [RFC3370], [RFC3394], [RFC3560], | The security considerations from [RFC3370], [RFC3394], [RFC3560], | |||
| [RFC3852], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], | [RFC5652], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], | |||
| [RFCTBD1], and [RFCTBD3] apply. | [RFC5754], and [RFCTBD1] apply. | |||
| The strength of any encryption scheme is only as good as its weakest | The strength of any encryption scheme is only as good as its weakest | |||
| link, which in the case of a PBES is the password. Passwords need to | link, which in the case of a PBES is the password. Passwords need to | |||
| provide sufficient entropy to ensure they cannot be easily guessed. | provide sufficient entropy to ensure they cannot be easily guessed. | |||
| The National Institute of Standards and Technology (NIST) Electronic | The U.S. National Institute of Standards and Technology (NIST) | |||
| Authentication Guidance [SP800-63] provides some information on | Electronic Authentication Guidance [SP800-63] provides some | |||
| password entropy. [SP800-63] indicates that a user chosen 20- | information on password entropy. [SP800-63] indicates that a user | |||
| character password from a 94-character keyboard with no checks | chosen 20-character password from a 94-character keyboard with no | |||
| provides 36 bits of entropy. If the 20-character password is | checks provides 36 bits of entropy. If the 20-character password is | |||
| randomly chosen, then the amount of entropy is increased to roughly | randomly chosen, then the amount of entropy is increased to roughly | |||
| 131 bits of entropy. The amount of entropy in the password does not | 131 bits of entropy. The amount of entropy in the password does not | |||
| correlate directly to bits of security but in general the more than | correlate directly to bits of security but in general the more than | |||
| the better. | the better. | |||
| The choice of content encryption algorithms for this document was | The choice of content encryption algorithms for this document was | |||
| based on [RFC5649]: "In the design of some high assurance | based on [RFC5649]: "In the design of some high assurance | |||
| cryptographic modules, it is desirable to segregate cryptographic | cryptographic modules, it is desirable to segregate cryptographic | |||
| keying material from other data. The use of a specific cryptographic | keying material from other data. The use of a specific cryptographic | |||
| mechanism solely for the protection of cryptographic keying material | mechanism solely for the protection of cryptographic keying material | |||
| skipping to change at page 6, line 32 ¶ | skipping to change at page 6, line 40 ¶ | |||
| [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) | [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) | |||
| Algorithms", RFC 3370, August 2002. | Algorithms", RFC 3370, August 2002. | |||
| [RFC3394] Housley, R., and J. Schaad, "Advanced Encryption Standard | [RFC3394] Housley, R., and J. Schaad, "Advanced Encryption Standard | |||
| (AES) Key Wrap Algorithm", RFC 3394, September 2002. | (AES) Key Wrap Algorithm", RFC 3394, September 2002. | |||
| [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport | [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport | |||
| Algorithm in the Cryptographic Message Syntax (CMS)", RFC | Algorithm in the Cryptographic Message Syntax (CMS)", RFC | |||
| 3560, July 2003. | 3560, July 2003. | |||
| [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC | ||||
| 3852, July 2004. | ||||
| [RFC4056] Schaad, J., "Use of RSASSA-PSS Signature Algorithm in | [RFC4056] Schaad, J., "Use of RSASSA-PSS Signature Algorithm in | |||
| Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. | Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. | |||
| [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- | [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- | |||
| 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC | 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC | |||
| 4231, December 2005 | 4231, December 2005 | |||
| [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) | [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) | |||
| Authenticated-Enveloped-Data Content Type", RFC 5083, | Authenticated-Enveloped-Data Content Type", RFC 5083, | |||
| November 2007. | November 2007. | |||
| [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated | [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated | |||
| Encryption in the Cryptographic Message Syntax (CMS)", | Encryption in the Cryptographic Message Syntax (CMS)", | |||
| RFC 5084, November 2007. | RFC 5084, November 2007. | |||
| [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) | ||||
| #8: Private-Key Information Syntax Specification Version | ||||
| 1.2", RFC 5208, May 2008. | ||||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation | Infrastructure Certificate and Certificate Revocation | |||
| List (CRL) Profile", RFC 5280, May 2008. | List (CRL) Profile", RFC 5280, May 2008. | |||
| [RFC5649] Housley, R., and M. Dworkin, "Advanced Encryption | [RFC5649] Housley, R., and M. Dworkin, "Advanced Encryption | |||
| Standard (AES) Key Wrap with Padding Algorithm", RFC | Standard (AES) Key Wrap with Padding Algorithm", RFC | |||
| 5649, August 2009. | 5649, August 2009. | |||
| [RFCTBD1] Turners, S., "Asymmetric Key Packages", draft-turner- | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC | |||
| asymmetrickeyformat-02.txt, work-in-progress. | 5652, September 2009. | |||
| [RFCTBD3] Turner, S., "Using SHA2 Algorithms with Cryptographic | ||||
| Message Syntax", draft-ietf-smime-sha2-11.txt, work-in- | ||||
| progress. | ||||
| [RFCTBD4] Turner, S., and B. Ramsdell, "Secure/Multipurpose | [RFC5751] Turner, S., and B. Ramsdell, "Secure/Multipurpose | |||
| Internet Mail Extensions (S/MIME) Version 3.2 Message | Internet Mail Extensions (S/MIME) Version 3.2 Message | |||
| Specification", draft-ietf-smime-3851bis-11.txt, work-in- | Specification", RFC 5751, January 2010. | |||
| progress. | ||||
| [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic | ||||
| Message Syntax", RFC 5754, January 2010. | ||||
| [RFCTBD1] Turners, S., "Asymmetric Key Packages", draft-turner- | ||||
| asymmetrickeyformat-03.txt, work-in-progress. | ||||
| /** | ||||
| RFC Editor: Please replace "RFCTBD1" with "RFC####" where #### is the | ||||
| number of the published RFC. Please do this in both the references | ||||
| and the text. | ||||
| **/ | ||||
| 8.2. Informative References | 8.2. Informative References | |||
| [SP800-57] National Institute of Standards and Technology (NIST), | [SP800-57] National Institute of Standards and Technology (NIST), | |||
| Special Publication 800-57: Recommendation for Key | Special Publication 800-57: Recommendation for Key | |||
| Management - Part 1 (Revised), March 2007. | Management - Part 1 (Revised), March 2007. | |||
| [SP800-63] National Institute of Standards and Technology (NIST), | [SP800-63] National Institute of Standards and Technology (NIST), | |||
| Special Publication 800-63: Electronic Authentication | Special Publication 800-63: Electronic Authentication | |||
| Guidance, April 2006. | Guidance, April 2006. | |||
| End of changes. 27 change blocks. | ||||
| 75 lines changed or deleted | 81 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||