[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          K. Burgin
Internet-Draft                                               A. Hennessy
Intended status: Informational                  National Security Agency
Expires: September 6, 2012                                 March 5, 2012


         Suite B Ciphersuites for the Bundle Security Protocol
               draft-hennessy-bsp-suiteb-ciphersuites-00

Abstract

   This document proposes eight ciphersuites for the Bundle Security
   Protocol (BSP), similar to the four suites specified in RFC 6257.
   The eight new ciphersuites provide compatibility with the United
   States National Security Agency's Suite B specifications.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 6, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Burgin & Hennessy       Expires September 6, 2012               [Page 1]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Suite B Ciphersuites . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Suites BAB-HMAC256 and BAB-HMAC384 . . . . . . . . . . . .  3
     3.2.  Suites PIB-ECDSA-SHA256 and PIB-ECDSA-SHA384 . . . . . . .  4
     3.3.  Suites PCB-ECDH-SHA256-AES128 and
           PCB-ECDH-SHA384-AES256 . . . . . . . . . . . . . . . . . .  5
     3.4.  Suites ESB-ECDH-SHA256-AES128 and
           ESB-ECDH-SHA384-AES256 . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




































Burgin & Hennessy       Expires September 6, 2012               [Page 2]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


1.  Introduction

   This document extends RFC 6257 and specifies eight ciphersuites for
   the Bundle Security Protocol.  The new suites provide compatibility
   with the United States National Security Agency's Suite B
   specifications.


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Suite B Ciphersuites

   This section defines eight new ciphersuites for use with the security
   block types BAB, PIB, PCB, and ESB.  The PIB ciphersuites are based
   on digital signatures using ECDSA.  The PCB and ESB ciphersuites use
   ECDH for key agreement, AES in Galois/Counter Mode (GCM) for content
   encryption, and AES Key Wrap for key encryption.  All proposed
   ciphersuites use SHA-256 or SHA-384 as the hash algorithm.

   The ciphersuites use the mechanisms defined in Cryptographic Message
   Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc., for
   transport in the appropriate security block.  Additionally, the
   ciphersuites follow the guidance and requirements of RFC 6318
   [RFC6318] which specifies the conventions for using Suite B
   algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME).

   CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
   Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
   [X.509-88].

3.1.  Suites BAB-HMAC256 and BAB-HMAC384

   The BAB-HMAC256 ciphersuite has ciphersuite ID value 0x05, and the
   BAB-HMAC384 ciphersuite has ciphersuite ID value 0x09.

   RFC 3370 [RFC3370] specifies the conventions for using HMAC with CMS
   and RFC 5754 [RFC5754] defines the algorithm identifiers for SHA-256
   and SHA-384.  MAC algorithm identifiers are located in the
   AuthenticatedData macAlgorithm field.  MAC values are located in the
   AuthenticatedData mac field.

   BAB-HMAC256 and BAB-HMAC384 use the strict canonicalization algorithm
   as described in [RFC6257], Section 3.4.1.  Strict canonicalization



Burgin & Hennessy       Expires September 6, 2012               [Page 3]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   supports digesting a fragment-bundle.  It does not permit the
   digesting of only a subset of the payload, but only the complete
   contents of the payload of the current bundle, which might be a
   fragment.  The fragment-range item for security-parameters is not
   used to indicate a fragment, as this information is digested within
   the primary block.

   These ciphersuites require the use of two related instances of the
   BAB.  It involves placing the first BAB instance just after the
   primary block.  The second (correlated) instance of the BAB MUST be
   placed after all other blocks (except possibly other BAB blocks) in
   the bundle.  Both required BAB instances MUST be included in the
   bundle before canonicalization.

   The security-result field is the output of the HMAC calculation with
   the input being the result of running the entire bundle through the
   strict canonicalization algorithm.  The security-parameters field is
   OPTIONAL, but if used, then the only field that can be present is
   key-information.

3.2.  Suites PIB-ECDSA-SHA256 and PIB-ECDSA-SHA384

   The PIB-ECDSA-SHA256 ciphersuite has ciphersuite ID value 0x06, and
   the PIB-ECDSA-SHA-384 ciphersuite has ciphersuite ID value 0x0A.

   In PIB-ECDSA-SHA256, ECDSA MUST be used with the SHA-256 message
   digest algorithm and the P-256 elliptic curve, as specified in
   [RFC6318].  In PIB-ECDSA-SHA384, ECDSA MUST be used with the SHA-384
   message digest algorithm and the P-384 elliptic curve, as specified
   in [RFC6318].  The P-256 and P-384 elliptic curves are specified in
   [DSS].

   The SHA-256 and SHA-384 message digest algorithms are defined in FIPS
   Pub 180-3 [RFC5754].  The algorithm identifiers for SHA-256 and SHA-
   384 are defined in [RFC5754].  RFC 5754 [RFC5754] specifies the
   conventions for using SHA-256 and SHA-384 with CMS.  Within the CMS
   signed-data content type, message digest algorithm identifiers are
   located in the SignedData digestAlgorithms field and the SignerInfo
   digestAlgorithm field.

   RFC 5753 [RFC5753] specifies the conventions for using ECDSA with
   CMS.  RFC 5480 [RFC5480] defines the signature algorithm identifiers
   used in CMS for ECDSA with SHA-256 and ECDSA with SHA-384.  Relevant
   details are repeated here.

   Within the CMS signed-data content type, signature algorithm
   identifiers are located in the SignerInfo signatureAlgorithm field of
   SignedData.  In addition, signature algorithm identifiers are located



Burgin & Hennessy       Expires September 6, 2012               [Page 4]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   in the SignerInfo signatureAlgorithm field of countersignature
   attributes.  When either signature algorithm identifier is used, the
   AlgorithmIdentifier parameters field MUST be absent.

   When signing, the ECDSA algorithm generates two values, commonly
   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 5480
   [RFC5480].

   These ciphersuites use a slightly modified form of the mutable
   canonicalization algorithm described in RFC 6257 [RFC6257], Section
   3.4.2, with the security-result data field for only the "current"
   block being excluded from the canonical form.  Additionally, the
   security-result length field for the "current" block is excluded from
   the mutable canonical form.  The resulting canonical form of the
   bundle is the input to the signing process.  These ciphersuites
   require the use of a single instance of the PIB.  The data to be
   signed is the output of the mutable canonicalization process.

   Because the signature field in SignedData SignatureValue is a
   security-result field, the entire key-information item MUST be placed
   in the block's security-result field, rather than security-
   parameters.

   If the bundle being signed has been fragmented before signing, then
   we have to specify which bytes were signed in case the signed bundle
   is subsequently fragmented for a second time.  If the bundle is a
   fragment, then the ciphersuite-parameters MUST include a fragment-
   range field, as described in [RFC6257], Section 2.6, specifying the
   offset and length of the signed fragment.  If the entire bundle is
   signed, then these numbers MUST be omitted.

3.3.  Suites PCB-ECDH-SHA256-AES128 and PCB-ECDH-SHA384-AES256

   The PCB-ECDH-SHA256-AES128 ciphersuite has ciphersuite ID value 0x07,
   and the PCB-ECDH-SHA384-AES256 ciphersuite has ciphersuite ID value
   0x0B.

   These schemes encrypt PIBs, PCBs, and the payload.  Both ciphersuites
   use ephemeral-static ECDH, which means that the security source
   possesses an ephemeral ECDH key pair and the security destination
   possesses a static ECDH key pair.

   When a key agreement algorithm is used in CMS, a key-encryption
   algorithm is also needed to encrypt the content encryption key (CEK).
   These ciphersuites use Advanced Encryption Standard (AES) Key Wrap,
   as specified in RFC 3394 [RFC3394] and [AESWRAP], as the key-
   encryption algorithm.  The key-encryption key used with the AES Key



Burgin & Hennessy       Expires September 6, 2012               [Page 5]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   Wrap algorithm is obtained from a key derivation function (KDF).
   These ciphersuites use a KDF based on SHA-256 and SHA-384.

   In PCB-ECDH-SHA256-AES128, ephemeral-static ECDH MUST be used with
   the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve, as
   specified in [RFC6318].  In PCB-ECDH-SHA384-AES256, ephemeral-static
   ECDH MUST be used with the SHA-384 KDF, AES-256 Key Wrap, and the
   P-384 elliptic curve, as specified in [RFC6318].  The P-256 and P-384
   elliptic curves are specified in [DSS].

   Section 3.1 of RFC 5753 [RFC5753] specifies the conventions for using
   ECDH with CMS.  Here the bundle encryption key (BEK), used to encrypt
   the BSP payload, is the data to be carried in a CMS enveloped-data
   content type.  CMS encrypts the BEK with a freshly generated content
   encryption key (CEK) and the result is placed in the encryptedContent
   field of an EnvelopedData EncryptedContentInfo structure.  The CEK is
   encrypted with the ECDH-generated pairwise key-encryption key (KEK)
   using the AES Key Wrap algorithm.  The result is placed in the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo
   RecipientEncryptedKey EncryptedKey field.

   Algorithm identifiers needed when using ECDH with CMS are provided in
   RFC 6318 [RFC6318] section 4.  Within the CMS enveloped-data content
   type, the key agreement algorithm identifier is placed in the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm field.  The key wrap algorithm identifier is
   placed in the KeyWrapAlgorithm parameters within the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.

   KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-
   encryption key from the shared secret produced by ephemeral-static
   ECDH.  Section 4.3 of RFC 6318 [RFC6318] specify the conventions for
   using the KDF with the shared secret generated with ephemeral-static
   ECDH with the CMS.

   BSP Payload encryption is done using the AES algorithm in Galois/
   Counter Mode (GCM) as described in [RFC5084].  For consistency with
   the description in [RFC5084], we refer to the GCM IV as a nonce.  The
   same key and nonce combination MUST NOT be used more than once.  The
   nonce has the same format as in RFC 6257 [RFC6257], where a salt
   field and iniialization vector field are concatenated to form the
   nonce.

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all PCBs that have the same correlator value.
   The salt need not be kept secret.

   The initialization vector (IV) is an eight-octet value, usually



Burgin & Hennessy       Expires September 6, 2012               [Page 6]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   chosen at random.  It MUST be different for all PCBs that have the
   same correlator value.  The value need not be kept secret.

   The BEK is a 16-octet (128 bits) value in PCB-ECDH-SHA256-AES128, and
   is a 32-octet value (256 bits) in PCB-ECDH-SHA384-AES256.  The BEK
   SHOULD be chosen randomly and MUST be kept secret.

   The Integrity Check Value (ICV) from the AES-GCM content encryption
   is a 16-octet value used to verify that the protected data has not
   been altered.  Normally, the ICV is concatenated with the ciphertext
   to produce the output of AES-GCM encryption.  However, to avoid
   expansion of the payload, the ICV value is placed in the security-
   result field of the first PCB.  The value need not be kept secret.

   These ciphersuites require the use of a single PCB instance to deal
   with payload confidentiality, as specified in [RFC6257], Section 4.3.

   For payload confidentiality, the first PCB MUST contain security-
   parameters and security-result fields.  The security-parameters field
   includes the salt, IV, and key-information items where the key-
   information item contains the encrypted BEK encoded in a CMS
   EnvelopedData structure.  The security-results-field contains the
   ICV.

   Subsequent PCBs MUST contain a correlator value to link them to the
   first PCB and MUST contain security-parameters and security-result
   fields.  The security-parameters field contains the IV for the
   specific block and the security-result field contains the
   encapsulated block.  For the payload, only the bytes of the bundle
   payload field are affected, being replaced by ciphertext.  The salt,
   IV, and key values specified in the first PCB are used to encrypt the
   payload, and the resultant authentication tag (ICV) is placed in an
   ICV item in the security-result field of that first PCB.  The other
   bytes of the payload block, such as type, flags, and length, are not
   modified.

   If the bundle being encrypted is a fragment-bundle, we have to
   specify which bytes are encrypted in case the bundle is subsequently
   fragmented again.  If the bundle is a fragment, the ciphersuite-
   parameters MUST include a fragment-range field.

   For each PIB or PCB to be protected, the entire original block is
   encapsulated in a "replacing" PCB.  This replacing PCB is placed in
   the outgoing bundle in the same position as the original block, PIB
   or PCB.

   The encryption process uses AES-GCM with the salt and key values from
   the first PCB, and an IV unique to this PCB.  The process creates



Burgin & Hennessy       Expires September 6, 2012               [Page 7]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   ciphertext for the entire original block and an authentication tag
   for validation at the security-destination.  For this encapsulation
   process, unlike the processing of the bundle payload, the
   authentication tag is appended to the ciphertext for the block, and
   the combination is stored into the encapsulated block item in the
   security-result.

   The replacing block has the same correlator value as the first PCB
   with which it is associated.  It also contains the block-specific IV
   in security-parameters, and the combination of original-block-
   ciphertext and authentication tag, stored as an encapsulated block
   item in the security-result.

3.4.  Suites ESB-ECDH-SHA256-AES128 and ESB-ECDH-SHA384-AES256

   The ESB-ECDH-SHA256-AES128 ciphersuite has ciphersuite ID value 0x08,
   and the ESB-ECDH-SHA384-AES256 ciphersuite has ciphersuite ID value
   0x0C.

   These schemes encrypt non-payload-related blocks.  They MUST NOT be
   used to encrypt PIBs, PCBs, or primary or payload blocks.  Both
   ciphersuites use ephemeral-static ECDH, which means that the security
   source uses an ephemeral ECDH key pair and the security destination
   uses a static ECDH key pair.

   When a key agreement algorithm is used in CMS, a key-encryption
   algorithm is also needed to encrypt the content encryption key (CEK).
   These ciphersuites use Advanced Encryption Standard (AES) Key Wrap,
   as specified in RFC 3394 [RFC3394] and [AESWRAP], as the key-
   encryption algorithm.  The key-encryption key used with the AES Key
   Wrap algorithm is obtained from a key derivation function (KDF).
   These ciphersuites use a KDF based on SHA-256 and SHA-384.

   In ESB-ECDH-SHA256-AES128, ephemeral-static ECDH MUST be used with
   the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve, as
   specified in [RFC6318].  In ESB-ECDH-SHA384-AES256, ephemeral-static
   ECDH MUST be used with the SHA-384 KDF, AES-256 Key Wrap, and the
   P-384 elliptic curve, as specified in [RFC6318].  The P-256 and P-384
   elliptic curves are specified in [DSS].

   Section 3.1 of RFC 5753 [RFC5753] specifies the conventions for using
   ECDH with CMS.  Within the CMS enveloped-data content type, key
   agreement algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
   The key wrap algorithm denotes the symmetric encryption algorithm
   used to encrypt the content-encryption key with the pairwise key-
   encryption key generated using the ephemeral-static ECDH key
   agreement algorithm.



Burgin & Hennessy       Expires September 6, 2012               [Page 8]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-
   encryption key from the shared secret produced by ephemeral-static
   ECDH.  Sections 7.1.8 and 7.2 of RFC 5753 [RFC5753] specify the
   conventions for using the KDF with the shared secret generated with
   ephemeral-static ECDH with CMS.

   Block encryption is done using the AES algorithm in Galois/Counter
   Mode (GCM) as described in [RFC5084].  For consistency with the
   description in [RFC5084], we refer to the GCM IV as a nonce.  The
   same key and nonce combination MUST NOT be used more than once.  The
   nonce has the same format as in RFC 6257 [RFC6257], where a salt
   field and iniialization vector field are concatenated to form the
   nonce.

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all ESBs that have the same correlator value.
   The salt need not be kept secret.

   The initialization vector (IV) is an eight-octet value, usually
   chosen at random.  It MUST be different for all ESBs that have the
   same correlator value.  The value need not be kept secret.

   The content encryption key, CEK (also called the bundle encryption
   key, BEK) is a 16-octet (128 bits) value in ESB-ECDH-SHA256-AES128,
   and is a 32-octet value (256 bits) in ESB-ECDH-SHA384-AES256.  The
   BEK SHOULD be chosen randomly and MUST be kept secret.

   The Integrity Check Value from the AES-GCM encryption of the payload
   is a 16-octet value used to verify that the protected data has not
   been altered.  The value need not be kept secret and is appended to
   the ciphertext for the block, and the combination is stored into the
   encapsulated block item in the security-result field.

   These ciphersuites replace each BP extension block to be protected
   with a "replacing" ESB, and each can be individually specified, as
   described in [RFC6257], Section 4.4.

   For each block to be protected, the entire original block is
   encapsulated in a "replacing" ESB.  This replacing ESB is placed in
   the outgoing bundle in the same position as the original block.

   The first ESB MUST contain security-parameters and security-result
   fields.  The security-parameters field contains the salt, IV, and
   key-information.  The security result field contains the encapsulated
   block.

   Subsequent ESBs MUST contain a correlator value to link them to the
   first ESB.  They MUST contain security-parameters that contain the IV



Burgin & Hennessy       Expires September 6, 2012               [Page 9]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   for the specific block and security-result field that contains the
   encapsulated block.

   The encryption process uses AES-GCM with the salt and key values from
   the first ESB and an IV unique to this ESB.  The process creates
   ciphertext for the entire original block, and an authentication tag
   for validation at the security-destination.  The authentication tag
   is appended to the ciphertext for the block and the combination is
   stored into the encapsulated block item in the security-result field.

   The replacing block has the same correlator value as the first ESB
   with which it is associated.  It also contains the block-specific IV
   in security-parameters, and the combination of original-block-
   ciphertext and authentication tag, stored as an encapsulated block
   item in the security-result field.


4.  Security 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.

   The security considerations in [RFC6257] discuss the Bundle Security
   Protocol and apply here as well.

   The security considerations in [RFC5652] discuss the CMS as a method
   for digitally signing data and encrypting data.

   The security considerations in [RFC3370] discuss cryptographic
   algorithm implementation concerns in the context of the CMS.

   The security considerations in [RFC5753] discuss the use of elliptic
   curve cryptography (ECC) in the CMS.

   The security considerations in [RFC3565] discuss the use of AES in
   the CMS, and the security considerations in [RFC5084] discuss the
   Galois/Counter Mode.


5.  IANA Considerations

   This protocol has fields that have been registered by IANA.

   The BSP has a ciphersuite number field and certain ciphersuites are
   defined.

   The registration policy for this registry is: Specification Required



Burgin & Hennessy       Expires September 6, 2012              [Page 10]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   The Value range is: Variable Length

   IANA is requested to assign the following values for the ciphersuite
   number field.

                       Ciphersuite Numbers Registry:

       +-------+--------------------------------------+----------------+
       | Value | Description                          | Reference      |
       +-------+--------------------------------------+----------------+
       |     5 | BAB-HMAC256                          | This document  |
       |     9 | BAB-HMAC384                          | This document  |
       |     6 | PIB-ECDSA-SHA256                     | This document  |
       |     A | PIB-ECDSA-SHA384                     | This document  |
       |     7 | PCB-ECDH-SHA256-AES128               | This document  |
       |     B | PCB-ECDH-SHA384-AES256               | This document  |
       |     8 | ESB-ECDH-SHA256-AES128               | This document  |
       |     C | ESB-ECDH-SHA256-AES128               | This document  |
       +-------+--------------------------------------+----------------+

                                 Figure 1


6.  Normative References

   [AESWRAP]  National Institute of Standards and Technology, "AES Key
              Wrap Specification", November 2001.

   [DSS]      National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-3, June 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, July 2003.

   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, November 2007.




Burgin & Hennessy       Expires September 6, 2012              [Page 11]

Internet-Draft        Suite B Ciphersuites for BSP            March 2012


   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", RFC 5753, January 2010.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, January 2010.

   [RFC6257]  Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification", RFC 6257,
              May 2011.

   [RFC6318]  Housley, R. and J. Solinas, "Suite B in Secure/
              Multipurpose Internet Mail Extensions (S/MIME)", RFC 6318,
              June 2011.


Authors' Addresses

   Kelley Burgin
   National Security Agency


   Email: kwburgi@tycho.ncsc.mil


   Angela Hennessy
   National Security Agency


   Email: amhenne@nsa.gov














Burgin & Hennessy       Expires September 6, 2012              [Page 12]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/