< draft-housley-smime-suite-b-01.txt   draft-housley-smime-suite-b-02.txt >
INTERNET DRAFT R. Housley INTERNET DRAFT R. Housley
Vigil Security Vigil Security
Expires October 2007 J. Solinas Expires December 2007 J. Solinas
April 2007 NSA June 2007 NSA
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
<draft-housley-smime-suite-b-01.txt> <draft-housley-smime-suite-b-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 5, line 21 skipping to change at page 5, line 21
bit of the OCTET STRING becomes the most significant bit of the BIT bit of the OCTET STRING becomes the most significant bit of the BIT
STRING, and the least significant bit of the OCTET STRING becomes STRING, and the least significant bit of the OCTET STRING becomes
the least significant bit of the BIT STRING. Note that this octet the least significant bit of the BIT STRING. Note that this octet
string may represent an elliptic curve point in compressed or string may represent an elliptic curve point in compressed or
uncompressed form. Implementations that support elliptic curves uncompressed form. Implementations that support elliptic curves
according to this specification MUST support the uncompressed form according to this specification MUST support the uncompressed form
and MAY support the compressed form. and MAY support the compressed form.
ECDSA and ECDH require use of certain parameters with the public key. ECDSA and ECDH require use of certain parameters with the public key.
The parameters may be inherited from the certificate issuer, The parameters may be inherited from the certificate issuer,
implicitly included through reference to a "named curve," or implicitly included through reference to a named curve, or explicitly
explicitly included in the certificate. As specified in RFC 3279 included in the certificate. As specified in RFC 3279 [PKIX1ALG],
[PKIX1ALG], the parameter structure is: the parameter structure is:
EcpkParameters ::= CHOICE { EcpkParameters ::= CHOICE {
ecParameters ECParameters, ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER, namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL } implicitlyCA NULL }
In Suite B, the namedCurve CHOICE MUST be used. The object In Suite B, the namedCurve CHOICE MUST be used. The object
identifier for P-256 is: identifier for P-256 is:
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 6, line 6 skipping to change at page 6, line 6
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
The algorithm identifier used in CMS for ECDSA with SHA-384 signature The algorithm identifier used in CMS for ECDSA with SHA-384 signature
values is: values is:
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
identifier is used, AlgorithmIdentifier parameters field MUST be identifier is used, the AlgorithmIdentifier parameters field MUST be
absent. absent.
When signing, the ECDSA algorithm generates two values, commonly When signing, the ECDSA algorithm generates two values, commonly
called r and s. To transfer these two values as one signature, they called r and s. To transfer these two values as one signature, they
MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279 MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279
[PKIX1ALG]: [PKIX1ALG]:
Ecdsa-Sig-Value ::= SEQUENCE { Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER } s INTEGER }
4. Key Management 4. Key Management
CMS accommodates the following general key management techniques: key CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key- agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords. In Suite B, key agreement MUST be encryption keys, and passwords. In Suite B, ephemeral-static key
used. agreement MUST be used as described in Section 4.1.
4.1. ECDH Key Agreement Algorithm
When a key agreement algorithm is used, a key-encryption algorithm is When a key agreement algorithm is used, a key-encryption algorithm is
also needed. In Suite B, the AES key Wrap as specified in RFC 3394 also needed. In Suite B, the AES key Wrap as specified in RFC 3394
[AESWRAP, SH] MUST be used as the key-encryption algorithm. AES Key [AESWRAP, SH] MUST be used as the key-encryption algorithm. AES Key
Wrap is discussed further in Section 4.2. The key-encryption key Wrap is discussed further in Section 4.2. The key-encryption key
used with the AES Key Wrap algorithm is obtained from a key used with the AES Key Wrap algorithm is obtained from a key
derivation function (KDF). In Suite B, there are two KDFs, one based derivation function (KDF). In Suite B, there are two KDFs, one based
on SHA-256 and one based on SHA-384. These KDFs are discussed on SHA-256 and one based on SHA-384. These KDFs are discussed
further in Section 4.3. further in Section 4.3.
4.1. ECDH Key Agreement Algorithm
This section specifies the conventions employed by implementations This section specifies the conventions employed by implementations
that support ECDH. The direction set by RFC 3278 [CMSECC] is that support ECDH. The direction set by RFC 3278 [CMSECC] is
followed, but additional key derivation functions and key wrap followed, but additional key derivation functions and key wrap
algorithms are employed. S/MIME is used in store-and-forward algorithms are employed. S/MIME is used in store-and-forward
communications, which means that ephemeral-static ECDH is always communications, which means that ephemeral-static ECDH is always
employed. This means that the message originator uses an ephemeral employed. This means that the message originator uses an ephemeral
ECDH key and that the message recipient uses a static ECDH key, which ECDH key and that the message recipient uses a static ECDH key, which
is obtained from an X.509 certificate. In Suite B Security Level 1, is obtained from an X.509 certificate. In Suite B Security Level 1,
ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 key ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 key
wrap, and the P-256 elliptic curve. In Suite B Security Level 2, wrap, and the P-256 elliptic curve. In Suite B Security Level 2,
skipping to change at page 7, line 20 skipping to change at page 7, line 20
[IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData [IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData
RecipientInfos keyAgreeRecipientInfo field is used as follows: RecipientInfos keyAgreeRecipientInfo field is used as follows:
version MUST be 3. version MUST be 3.
originator MUST be the originatorKey alternative. The originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the id-ecPublicKey originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 3) with NULL parameters. The object identifier (see Section 3) with NULL parameters. The
originatorKey publicKey field MUST contain the message originatorKey publicKey field MUST contain the message
originator's ephemeral public key, which is a DER-encoded ECPoint originator's ephemeral public key, which is a DER-encoded ECPoint
(see Section 3). (see Section 3). The ECPoint SHOULD be represented in
uncompressed form.
ukm can be present or absent. However, message originators SHOULD ukm can be present or absent. However, message originators SHOULD
include the ukm to be compliant with this specification. include the ukm. As specified in RFC 3852 [CMS], implementations
Implementations SHOULD support the ukm being absent for message MUST support ukm message recipient processing, so interoperability
recipient processing. When present, the ukm is used to ensure is not a concern if the ukm is present or absent. When present,
that a different key-encryption key is generated, even when the the ukm is used to ensure that a different key-encryption key is
ephemeral private key is improperly used more than once. See generated, even when the ephemeral private key is improperly used
[RANDOM] for guidance on generation of random values. more than once. See [RANDOM] for guidance on generation of random
values.
keyEncryptionAlgorithm MUST be one of the two algorithm keyEncryptionAlgorithm MUST be one of the two algorithm
identifiers listed below, and the algorithm identifier parameter identifiers listed below, and the algorithm identifier parameter
field MUST be present and identify the key wrap algorithm. The field MUST be present and identify the key wrap algorithm. The
key wrap algorithm denotes the symmetric encryption algorithm used key wrap algorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the ephemeral-static ECDH key encryption key generated using the ephemeral-static ECDH key
agreement algorithm. In Suite B Security Level 1, the agreement algorithm (see Section 4.3). In Suite B Security Level
keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha256kdf- 1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-
scheme, and the keyEncryptionAlgorithm parameter MUST be a sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be
KeyWrapAlgorithm containing id-aes128-wrap. In Suite B Security a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2).
Level 2, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH- In Suite B Security Level 2, the keyEncryptionAlgorithm MUST be
sha384kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the
a KeyWrapAlgorithm containing id-aes256-wrap. The algorithm keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm
containing id-aes256-wrap (see Section 4.2). The algorithm
identifier for dhSinglePass-stdDH-sha256kdf-scheme and identifier for dhSinglePass-stdDH-sha256kdf-scheme and
dhSinglePass-stdDH-sha384kdf-scheme are: dhSinglePass-stdDH-sha384kdf-scheme are:
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132) { iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 } schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132) { iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 } schemes(1) 11 2 }
skipping to change at page 8, line 29 skipping to change at page 8, line 29
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static ECDH public key. certificate contains the recipient's static ECDH public key.
RecipientEncryptedKey EncryptedKey MUST contain the content- RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the ephemeral-static ECDH generated encryption key encrypted with the ephemeral-static ECDH generated
pairwise key-encryption key using the algorithm specified by the pairwise key-encryption key using the algorithm specified by the
KeyWrapAlgorithm. KeyWrapAlgorithm (see section 4.3).
4.2. AES Key Wrap 4.2. AES Key Wrap
CMS offers support for symmetric key-encryption key management; CMS offers support for symmetric key-encryption key management;
however, it is not used in Suite B. Rather, the AES Key Wrap key- however, it is not used in Suite B. Rather, the AES Key Wrap key-
encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used
to encrypt the content-encryption key with a pairwise key-encryption to encrypt the content-encryption key with a pairwise key-encryption
key that is generated using ephemeral-static ECDH. In Suite B key that is generated using ephemeral-static ECDH. In Suite B
Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption
algorithm. In Suite B Security Level 2, AES-256 Key Wrap MUST be algorithm. In Suite B Security Level 2, AES-256 Key Wrap MUST be
skipping to change at page 10, line 22 skipping to change at page 10, line 26
because the KDF specified in [SEC1] ensures that sufficient keying because the KDF specified in [SEC1] ensures that sufficient keying
data is provided. data is provided.
The KDF specified in [SEC1] provides an algorithm for generating an The KDF specified in [SEC1] provides an algorithm for generating an
essentially arbitrary amount of keying material from the shared essentially arbitrary amount of keying material from the shared
secret produced by ephemeral-static ECDH, which is called Z for the secret produced by ephemeral-static ECDH, which is called Z for the
remainder of this discussion. The KDF can be summarized as: remainder of this discussion. The KDF can be summarized as:
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo ) KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
To generate a key-encryption key, one or more KM blocks are
generated, incrementing Counter appropriately, until enough material
has been generated. The KM blocks are concatenated left to right:
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
The elements of the KDF are used as follows: The elements of the KDF are used as follows:
Hash is the one-way hash function, and it is either SHA-256 or Hash is the one-way hash function, and it is either SHA-256 or
SHA-384 [SHA2]. In Suite B Security Level 1, the SHA-256 MUST be SHA-384 [SHA2]. In Suite B Security Level 1, the SHA-256 MUST be
used. In Suite B Security Level 2, SHA-384 MUST be used. used. In Suite B Security Level 2, SHA-384 MUST be used.
Z is the shared secret value generated by ephemeral-static ECDH. Z is the shared secret value generated by ephemeral-static ECDH.
Leading zero bits MUST be preserved. In Suite B Security Level 1, Leading zero bits MUST be preserved. In Suite B Security Level 1,
Z MUST be exactly 256 bits. In Suite B Security Level 2, Z MUST Z MUST be exactly 256 bits. In Suite B Security Level 2, Z MUST
be exactly 384 bits. be exactly 384 bits.
skipping to change at page 10, line 43 skipping to change at page 11, line 6
Counter is a 32 bit unsigned number, represented in network byte Counter is a 32 bit unsigned number, represented in network byte
order. Its initial value MUST be 0x00000001 for any key order. Its initial value MUST be 0x00000001 for any key
derivation operation. In Suite B Security Level 1 and Security derivation operation. In Suite B Security Level 1 and Security
Level 2, exactly one iteration is needed; the Counter is not Level 2, exactly one iteration is needed; the Counter is not
incremented. incremented.
ECC-CMS-SharedInfo is composed as described above. It MUST be DER ECC-CMS-SharedInfo is composed as described above. It MUST be DER
encoded. encoded.
To generate a key-encryption key, one KM block is generated, with a To generate a key-encryption key, one KM block is generated, with a
Counter value of 0x00000001. The KM blocks are concatenated left to Counter value of 0x00000001:
right:
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo ) KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
In Suite B Security Level 1, the key-encryption key MUST be the most In Suite B Security Level 1, the key-encryption key MUST be the most
significant 128 bits of the SHA-256 output value. In Suite B significant 128 bits of the SHA-256 output value. In Suite B
Security Level 2, the key-encryption key MUST be the most significant Security Level 2, the key-encryption key MUST be the most significant
256 bits of the SHA-384 output value. 256 bits of the SHA-384 output value.
Note that the only source of secret entropy in this computation is Z. Note that the only source of secret entropy in this computation is Z.
The effective key space of the key-encryption key is limited by the The effective key space of the key-encryption key is limited by the
skipping to change at page 11, line 45 skipping to change at page 12, line 10
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 } nistAlgorithm(4) aes(1) 42 }
The AlgorithmIdentifier parameters field MUST be present, and the The AlgorithmIdentifier parameters field MUST be present, and the
parameters field must contain AES-IV: parameters field must contain AES-IV:
AES-IV ::= OCTET STRING (SIZE(16)) AES-IV ::= OCTET STRING (SIZE(16))
The 16 octet initialization vector is generated at random by the
originator. See [RANDOM] for guidance on generation of random
values.
6. Security Considerations 6. Security Considerations
This document specifies the conventions for using the NSA's Suite B This document specifies the conventions for using the NSA's Suite B
algorithms in S/MIME. All of the algorithms have been specified in algorithms in S/MIME. All of the algorithms have been specified in
previous documents, although a few new algorithm identifiers have previous documents, although a few new algorithm identifiers have
been assigned. As a result, there are no new security been assigned.
considerations.
Two levels of security may be achieved using this specification.
Users must consider their risk environment to determine which level
is appropriate for their own use.
For signed and encrypted messages, Suite B provides a consistent
level of security for confidentiality and integrity of the message
content.
The security considerations in RFC 3852 [CMS] discuss the CMS as a The security considerations in RFC 3852 [CMS] discuss the CMS as a
method for digitally signing data and encrypting data. method for digitally signing data and encrypting data.
The security considerations in RFC 3370 [CMSALG] discuss The security considerations in RFC 3370 [CMSALG] discuss
cryptographic algorithm implementation concerns in the context of the cryptographic algorithm implementation concerns in the context of the
CMS. CMS.
The security considerations in RFC 3278 [CMSECC] discuss the use of The security considerations in RFC 3278 [CMSECC] discuss the use of
elliptic curve cryptography (ECC) in the CMS. elliptic curve cryptography (ECC) in the CMS.
skipping to change at page 12, line 26 skipping to change at page 12, line 50
AES in the CMS. AES in the CMS.
7. References 7. References
7.1. Normative References 7.1. Normative References
[AES] National Institute of Standards and Technology, "Advanced [AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001. Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AESWRAP] National Institute of Standards and Technology, "AES Key [AESWRAP] National Institute of Standards and Technology, "AES Key
Wrap Specification," 17 November 2001. [See Wrap Specification", 17 November 2001. [See
http://csrc.nist.gov/encryption/kms/key-wrap.pdf] http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-2, January 2000. Signature Standard (DSS)", FIPS PUB 186-2, January 2000.
[ECDSA] ANSI X9.62-1998, "Public Key Cryptography For The [ECDSA] American National Standards Institute, "Public Key
Financial Services Industry: The Elliptic Curve Digital Cryptography For The Financial Services Industry: The
Signature Algorithm (ECDSA)", American National Elliptic Curve Digital Signature Algorithm (ECDSA)",
Standards Institute, 1999. ANSI X9.62-1998, 1999.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message (AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003. Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
skipping to change at page 13, line 14 skipping to change at page 13, line 35
[CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of [CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", RFC 3278, Cryptographic Message Syntax (CMS)", RFC 3278,
April 2002. April 2002.
[IEEE1363] Institute of Electrical and Electronics Engineers, [IEEE1363] Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography", "Standard Specifications for Public Key Cryptography",
IEEE Std 1363, 2000. IEEE Std 1363, 2000.
[MODES] National Institute of Standards and Technology. FIPS [MODES] National Institute of Standards and Technology, "DES
Pub 81: DES Modes of Operation. 2 December 1980. Modes of Operation", FIPS Pub 81, 2 December 1980.
[MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail [MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[PKIX1ALG] Polk, W., Housley, R., and L. Bassham, "Algorithms and [PKIX1ALG] Polk, W., Housley, R., and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002. List (CRL) Profile", RFC 3279, April 2002.
[SEC1] Standards for Efficient Cryptography Group, "Elliptic [SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/ Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.] collateral/sec1.pdf.]
[SH] Schaad, J., and R. Housley, "Advanced Encryption Standard [SH] Schaad, J., and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002. (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SHA2] National Institute of Standards and Technology (NIST), [SHA2] National Institute of Standards and Technology, "Secure
FIPS 180-2: Secure Hash Standard, 1 August 2002. Hash Standard", FIPS 180-2, 1 August 2002.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
 End of changes. 19 change blocks. 
40 lines changed or deleted 59 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/