Skip to main content

CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-10

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9052.
Author Jim Schaad
Last updated 2020-06-18 (Latest revision 2020-06-02)
Replaces draft-schaad-cose-rfc8152bis-struct
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Matthew A. Miller
Shepherd write-up Show Last changed 2020-01-15
IESG IESG state Became RFC 9052 (Internet Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 6 more YES or NO OBJECTION positions to pass.
Responsible AD Barry Leiba
Send notices to Matthew Miller <linuxwolf+ietf@outer-planes.net>
IANA IANA review state IANA OK - Actions Needed
draft-ietf-cose-rfc8152bis-struct-10
gt;.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC4998]  Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
              Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
              August 2007, <https://www.rfc-editor.org/info/rfc4998>.

   [I-D.ietf-cose-hash-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Hash Algorithms", Work in Progress, Internet-Draft, draft-
              ietf-cose-hash-algs-04, 29 May 2020,
              <https://tools.ietf.org/html/draft-ietf-cose-hash-algs-
              04>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              00, 30 March 2020, <https://tools.ietf.org/html/draft-
              ietf-core-groupcomm-bis-00>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

Appendix A.  Guidelines for External Data Authentication of Algorithms

   During development of COSE, the requirement that the algorithm
   identifier be located in the protected attributes was relaxed from a
   must to a should.  There were two basic reasons that have been
   advanced to support this position.  First, the resulting message will
   be smaller if the algorithm identifier is omitted from the most
   common messages in a CoAP environment.  Second, there is a potential
   bug that will arise if full checking is not done correctly between
   the different places that an algorithm identifier could be placed
   (the message itself, an application statement, the key structure that
   the sender possesses, and the key structure the recipient possesses).

Schaad                   Expires 4 December 2020               [Page 61]
Internet-Draft               COSE Structure                    June 2020

   This appendix lays out how such a change can be made and the details
   that an application needs to specify in order to use this option.
   Two different sets of details are specified: those needed to omit an
   algorithm identifier and those needed to use a variant on the counter
   signature attribute that contains no attributes about itself.

   Three sets of recommendations are laid out.  The first set of
   recommendations applies to having an implicit algorithm identified
   for a single layer of a COSE object.  The second set of
   recommendations applies to having multiple implicit algorithms
   identified for multiple layers of a COSE object.  The third set of
   recommendations applies to having implicit algorithms for multiple
   COSE object constructs.

   The key words from [RFC2119] are deliberately not used here.  This
   specification can provide recommendations, but it cannot enforce
   them.

   This set of recommendations applies to the case where an application
   is distributing a fixed algorithm along with the key information for
   use in a single COSE object.  This normally applies to the smallest
   of the COSE objects, specifically COSE_Sign1, COSE_Mac0, and
   COSE_Encrypt0, but could apply to the other structures as well.

   The following items should be taken into account:

   *  Applications need to list the set of COSE structures that implicit
      algorithms are to be used in.  Applications need to require that
      the receipt of an explicit algorithm identifier in one of these
      structures will lead to the message being rejected.  This
      requirement is stated so that there will never be a case where
      there is any ambiguity about the question of which algorithm
      should be used, the implicit or the explicit one.  This applies
      even if the transported algorithm identifier is a protected
      attribute.  This applies even if the transported algorithm is the
      same as the implicit algorithm.

   *  Applications need to define the set of information that is to be
      considered to be part of a context when omitting algorithm
      identifiers.  At a minimum, this would be the key identifier (if
      needed), the key, the algorithm, and the COSE structure it is used
      with.  Applications should restrict the use of a single key to a
      single algorithm.  As noted for some of the algorithms in
      [I-D.ietf-cose-rfc8152bis-algs], the use of the same key in
      different related algorithms can lead to leakage of information
      about the key, leakage about the data or the ability to perform
      forgeries.

Schaad                   Expires 4 December 2020               [Page 62]
Internet-Draft               COSE Structure                    June 2020

   *  In many cases, applications that make the algorithm identifier
      implicit will also want to make the context identifier implicit
      for the same reason.  That is, omitting the context identifier
      will decrease the message size (potentially significantly
      depending on the length of the identifier).  Applications that do
      this will need to describe the circumstances where the context
      identifier is to be omitted and how the context identifier is to
      be inferred in these cases.  (An exhaustive search over all of the
      keys would normally not be considered to be acceptable.)  An
      example of how this can be done is to tie the context to a
      transaction identifier.  Both would be sent on the original
      message, but only the transaction identifier would need to be sent
      after that point as the context is tied into the transaction
      identifier.  Another way would be to associate a context with a
      network address.  All messages coming from a single network
      address can be assumed to be associated with a specific context.
      (In this case, the address would normally be distributed as part
      of the context.)

   *  Applications cannot rely on key identifiers being unique unless
      they take significant efforts to ensure that they are computed in
      such a way as to create this guarantee.  Even when an application
      does this, the uniqueness might be violated if the application is
      run in different contexts (i.e., with a different context
      provider) or if the system combines the security contexts from
      different applications together into a single store.

   *  Applications should continue the practice of protecting the
      algorithm identifier.  Since this is not done by placing it in the
      protected attributes field, applications should define an
      application-specific external data structure that includes this
      value.  This external data field can be used as such for content
      encryption, MAC, and signature algorithms.  It can be used in the
      SuppPrivInfo field for those algorithms that use a KDF to derive a
      key value.  Applications may also want to protect other
      information that is part of the context structure as well.  It
      should be noted that those fields, such as the key or a Base IV,
      are protected by virtue of being used in the cryptographic
      computation and do not need to be included in the external data
      field.

Schaad                   Expires 4 December 2020               [Page 63]
Internet-Draft               COSE Structure                    June 2020

   The second case is having multiple implicit algorithm identifiers
   specified for a multiple layer COSE object.  An example of how this
   would work is the encryption context that an application specifies,
   which contains a content encryption algorithm, a key wrap algorithm,
   a key identifier, and a shared secret.  The sender omits sending the
   algorithm identifier for both the content layer and the recipient
   layer leaving only the key identifier.  The receiver then uses the
   key identifier to get the implicit algorithm identifiers.

   The following additional items need to be taken into consideration:

   *  Applications that want to support this will need to define a
      structure that allows for, and clearly identifies, both the COSE
      structure to be used with a given key and the structure and
      algorithm to be used for the secondary layer.  The key for the
      secondary layer is computed as normal from the recipient layer.

   The third case is having multiple implicit algorithm identifiers, but
   targeted at potentially unrelated layers or different COSE objects.
   There are a number of different scenarios where this might be
   applicable.  Some of these scenarios are:

   *  Two contexts are distributed as a pair.  Each of the contexts is
      for use with a COSE_Encrypt message.  Each context will consist of
      distinct secret keys and IVs and potentially even different
      algorithms.  One context is for sending messages from party A to
      party B, and the second context is for sending messages from party
      B to party A.  This means that there is no chance for a reflection
      attack to occur as each party uses different secret keys to send
      its messages; a message that is reflected back to it would fail to
      decrypt.

   *  Two contexts are distributed as a pair.  The first context is used
      for encryption of the message, and the second context is used to
      place a counter signature on the message.  The intention is that
      the second context can be distributed to other entities
      independently of the first context.  This allows these entities to
      validate that the message came from an individual without being
      able to decrypt the message and see the content.

   *  Two contexts are distributed as a pair.  The first context
      contains a key for dealing with MACed messages, and the second
      context contains a different key for dealing with encrypted
      messages.  This allows for a unified distribution of keys to
      participants for different types of messages that have different
      keys, but where the keys may be used in a coordinated manner.

Schaad                   Expires 4 December 2020               [Page 64]
Internet-Draft               COSE Structure                    June 2020

   For these cases, the following additional items need to be
   considered:

   *  Applications need to ensure that the multiple contexts stay
      associated.  If one of the contexts is invalidated for any reason,
      all of the contexts associated with it should also be invalidated.

Appendix B.  Two Layers of Recipient Information

   All of the currently defined recipient algorithm classes only use two
   layers of the COSE_Encrypt structure.  The first layer is the message
   content, and the second layer is the content key encryption.
   However, if one uses a recipient algorithm such as the RSA Key
   Encapsulation Mechanism (RSA-KEM) (see Appendix A of RSA-KEM
   [RFC5990]), then it makes sense to have three layers of the
   COSE_Encrypt structure.

   These layers would be:

   *  Layer 0: The content encryption layer.  This layer contains the
      payload of the message.

   *  Layer 1: The encryption of the CEK by a KEK.

   *  Layer 2: The encryption of a long random secret using an RSA key
      and a key derivation function to convert that secret into the KEK.

   This is an example of what a triple layer message would look like.
   The message has the following layers:

   *  Layer 0: Has a content encrypted with AES-GCM using a 128-bit key.

   *  Layer 1: Uses the AES Key Wrap algorithm with a 128-bit key.

   *  Layer 2: Uses ECDH Ephemeral-Static direct to generate the layer 1
      key.

   In effect, this example is a decomposed version of using the
   ECDH-ES+A128KW algorithm.

   Size of binary file is 183 bytes

Schaad                   Expires 4 December 2020               [Page 65]
Internet-Draft               COSE Structure                    June 2020

   96(
     [
       / protected / h'a10101' / {
           \ alg \ 1:1 \ AES-GCM 128 \
         } / ,
       / unprotected / {
         / iv / 5:h'02d1f7e6f26c43d4868d87ce'
       },
       / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0
   811139868826e89218a75715b',
       / recipients / [
         [
           / protected / h'',
           / unprotected / {
             / alg / 1:-3 / A128KW /
           },
           / ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82
   18f11',
           / recipients / [
             [
               / protected / h'a1013818' / {
                   \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
                 } / ,
               / unprotected / {
                 / ephemeral / -1:{
                   / kty / 1:2,
                   / crv / -1:1,
                   / x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11
   e9b8a55a600b21233e86e68',
                   / y / -3:false
                 },
                 / kid / 4:'meriadoc.brandybuck@buckland.example'
               },
               / ciphertext / h''
             ]
           ]
         ]
       ]
     ]
   )

Appendix C.  Examples

   This appendix includes a set of examples that show the different
   features and message types that have been defined in this document.
   To make the examples easier to read, they are presented using the
   extended CBOR diagnostic notation (defined in [RFC8610]) rather than
   as a binary dump.

Schaad                   Expires 4 December 2020               [Page 66]
Internet-Draft               COSE Structure                    June 2020

   A GitHub project has been created at <https://github.com/cose-wg/
   Examples> that contains not only the examples presented in this
   document, but a more complete set of testing examples as well.  Each
   example is found in a JSON file that contains the inputs used to
   create the example, some of the intermediate values that can be used
   in debugging the example and the output of the example presented both
   as a hex dump and in CBOR diagnostic notation format.  Some of the
   examples at the site are designed failure testing cases; these are
   clearly marked as such in the JSON file.  If errors in the examples
   in this document are found, the examples on GitHub will be updated,
   and a note to that effect will be placed in the JSON file.

   As noted, the examples are presented using the CBOR's diagnostic
   notation.  A Ruby-based tool exists that can convert between the
   diagnostic notation and binary.  This tool can be installed with the
   command line:

   gem install cbor-diag

   The diagnostic notation can be converted into binary files using the
   following command line:

   diag2cbor.rb < inputfile > outputfile

   The examples can be extracted from the XML version of this document
   via an XPath expression as all of the sourcecode is tagged with the
   attribute type='CBORdiag'.  (Depending on the XPath evaluator one is
   using, it may be necessary to deal with &gt; as an entity.)

   //sourcecode[@type='CDDL']/text()

C.1.  Examples of Signed Messages

C.1.1.  Single Signature

   This example uses the following:

   *  Signature Algorithm: ECDSA w/ SHA-256, Curve P-256

   Size of binary file is 103 bytes

Schaad                   Expires 4 December 2020               [Page 67]
Internet-Draft               COSE Structure                    June 2020

   98(
     [
       / protected / h'',
       / unprotected / {},
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected / h'a10126' / {
               \ alg \ 1:-7 \ ECDSA 256 \
             } / ,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
   5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
   98f53afd2fa0f30a'
         ]
       ]
     ]
   )

C.1.2.  Multiple Signers

   This example uses the following:

   *  Signature Algorithm: ECDSA w/ SHA-256, Curve P-256

   *  Signature Algorithm: ECDSA w/ SHA-512, Curve P-521

   Size of binary file is 277 bytes

Schaad                   Expires 4 December 2020               [Page 68]
Internet-Draft               COSE Structure                    June 2020

   98(
     [
       / protected / h'',
       / unprotected / {},
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected / h'a10126' / {
               \ alg \ 1:-7 \ ECDSA 256 \
             } / ,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
   5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
   98f53afd2fa0f30a'
         ],
         [
           / protected / h'a1013823' / {
               \ alg \ 1:-36
             } / ,
           / unprotected / {
             / kid / 4:'bilbo.baggins@hobbiton.example'
           },
           / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
   de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
   7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
   c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
   83ab87bb4f7a0297'
         ]
       ]
     ]
   )

C.1.3.  Counter Signature

   This example uses the following:

   *  Signature Algorithm: ECDSA w/ SHA-256, Curve P-256

   *  The same header parameters are used for both the signature and the
      counter signature.

   Size of binary file is 180 bytes

Schaad                   Expires 4 December 2020               [Page 69]
Internet-Draft               COSE Structure                    June 2020

   98(
     [
       / protected / h'',
       / unprotected / {
         / countersign / 7:[
           / protected / h'a10126' / {
               \ alg \ 1:-7 \ ECDSA 256 \
             } / ,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4
   9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e
   8802bb6650cceb2c'
         ]
       },
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected / h'a10126' / {
               \ alg \ 1:-7 \ ECDSA 256 \
             } / ,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
   5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
   98f53afd2fa0f30a'
         ]
       ]
     ]
   )

C.1.4.  Signature with Criticality

   This example uses the following:

   *  Signature Algorithm: ECDSA w/ SHA-256, Curve P-256

   *  There is a criticality marker on the "reserved" header parameter

   Size of binary file is 125 bytes

Schaad                   Expires 4 December 2020               [Page 70]
Internet-Draft               COSE Structure                    June 2020

   98(
     [
       / protected / h'a2687265736572766564f40281687265736572766564' /
   {
           "reserved":false,
           \ crit \ 2:[
             "reserved"
           ]
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected / h'a10126' / {
               \ alg \ 1:-7 \ ECDSA 256 \
             } / ,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
   69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
   18aba9d1fad1bd9c'
         ]
       ]
     ]
   )

C.2.  Single Signer Examples

C.2.1.  Single ECDSA Signature

   This example uses the following:

   *  Signature Algorithm: ECDSA w/ SHA-256, Curve P-256

   Size of binary file is 98 bytes

Schaad                   Expires 4 December 2020               [Page 71]
Internet-Draft               COSE Structure                    June 2020

   18(
     [
       / protected / h'a10126' / {
           \ alg \ 1:-7 \ ECDSA 256 \
         } / ,
       / unprotected / {
         / kid / 4:'11'
       },
       / payload / 'This is the content.',
       / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
   d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
   a4c345cacb36'
     ]
   )

C.3.  Examples of Enveloped Messages

C.3.1.  Direct ECDH

   This example uses the following:

   *  CEK: AES-GCM w/ 128-bit key

   *  Recipient class: ECDH Ephemeral-Static, Curve P-256

   Size of binary file is 151 bytes

Schaad                   Expires 4 December 2020               [Page 72]
Internet-Draft               COSE Structure                    June 2020

   96(
     [
       / protected / h'a10101' / {
           \ alg \ 1:1 \ AES-GCM 128 \
         } / ,
       / unprotected / {
         / iv / 5:h'c9cf4df2fe6c632bf7886413'
       },
       / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
   c52a357da7a644b8070a151b0',
       / recipients / [
         [
           / protected / h'a1013818' / {
               \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
             } / ,
           / unprotected / {
             / ephemeral / -1:{
               / kty / 1:2,
               / crv / -1:1,
               / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
   bf054e1c7b4d91d6280',
               / y / -3:true
             },
             / kid / 4:'meriadoc.brandybuck@buckland.example'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

C.3.2.  Direct Plus Key Derivation

   This example uses the following:

   *  CEK: AES-CCM w/ 128-bit key, truncate the tag to 64 bits

   *  Recipient class: Use HKDF on a shared secret with the following
      implicit fields as part of the context.

      -  salt: "aabbccddeeffgghh"

      -  PartyU identity: "lighting-client"

      -  PartyV identity: "lighting-server"

      -  Supplementary Public Other: "Encryption Example 02"

Schaad                   Expires 4 December 2020               [Page 73]
Internet-Draft               COSE Structure                    June 2020

   Size of binary file is 91 bytes

   96(
     [
       / protected / h'a1010a' / {
           \ alg \ 1:10 \ AES-CCM-16-64-128 \
         } / ,
       / unprotected / {
         / iv / 5:h'89f52f65a1c580933b5261a76c'
       },
       / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
   1b687b847',
       / recipients / [
         [
           / protected / h'a10129' / {
               \ alg \ 1:-10
             } / ,
           / unprotected / {
             / salt / -20:'aabbccddeeffgghh',
             / kid / 4:'our-secret'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

C.3.3.  Counter Signature on Encrypted Content

   This example uses the following:

   *  CEK: AES-GCM w/ 128-bit key

   *  Recipient class: ECDH Ephemeral-Static, Curve P-256

   Size of binary file is 326 bytes

Schaad                   Expires 4 December 2020               [Page 74]
Internet-Draft               COSE Structure                    June 2020

   96(
     [
       / protected / h'a10101' / {
           \ alg \ 1:1 \ AES-GCM 128 \
         } / ,
       / unprotected / {
         / iv / 5:h'c9cf4df2fe6c632bf7886413',
         / countersign / 7:[
           / protected / h'a1013823' / {
               \ alg \ 1:-36
             } / ,
           / unprotected / {
             / kid / 4:'bilbo.baggins@hobbiton.example'
           },
           / signature / h'00929663c8789bb28177ae28467e66377da12302d7f9
   594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f
   cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00
   3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c
   c3430c9d65e7ddff'
         ]
       },
       / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
   c52a357da7a644b8070a151b0',
       / recipients / [
         [
           / protected / h'a1013818' / {
               \ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
             } / ,
           / unprotected / {
             / ephemeral / -1:{
               / kty / 1:2,
               / crv / -1:1,
               / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
   bf054e1c7b4d91d6280',
               / y / -3:true
             },
             / kid / 4:'meriadoc.brandybuck@buckland.example'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

C.3.4.  Encrypted Content with External Data

   This example uses the following:

Schaad                   Expires 4 December 2020               [Page 75]
Internet-Draft               COSE Structure                    June 2020

   *  CEK: AES-GCM w/ 128-bit key

   *  Recipient class: ECDH static-Static, Curve P-256 with AES Key Wrap

   *  Externally Supplied AAD: h'0011bbcc22dd44ee55ff660077'

   Size of binary file is 173 bytes

   96(
     [
       / protected / h'a10101' / {
           \ alg \ 1:1 \ AES-GCM 128 \
         } / ,
       / unprotected / {
         / iv / 5:h'02d1f7e6f26c43d4868d87ce'
       },
       / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
   e5f0165eee976b4a5f6c6f09d',
       / recipients / [
         [
           / protected / h'a101381f' / {
               \ alg \ 1:-32 \ ECHD-SS+A128KW \
             } / ,
           / unprotected / {
             / static kid / -3:'peregrin.took@tuckborough.example',
             / kid / 4:'meriadoc.brandybuck@buckland.example',
             / U nonce / -22:h'0101'
           },
           / ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
   e1c62'
         ]
       ]
     ]
   )

C.4.  Examples of Encrypted Messages

C.4.1.  Simple Encrypted Message

   This example uses the following:

   *  CEK: AES-CCM w/ 128-bit key and a 64-bit tag

   Size of binary file is 52 bytes

Schaad                   Expires 4 December 2020               [Page 76]
Internet-Draft               COSE Structure                    June 2020

   16(
     [
       / protected / h'a1010a' / {
           \ alg \ 1:10 \ AES-CCM-16-64-128 \
         } / ,
       / unprotected / {
         / iv / 5:h'89f52f65a1c580933b5261a78c'
       },
       / ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
   460ffb569'
     ]
   )

C.4.2.  Encrypted Message with a Partial IV

   This example uses the following:

   *  CEK: AES-CCM w/ 128-bit key and a 64-bit tag

   *  Prefix for IV is 89F52F65A1C580933B52

   Size of binary file is 41 bytes

   16(
     [
       / protected / h'a1010a' / {
           \ alg \ 1:10 \ AES-CCM-16-64-128 \
         } / ,
       / unprotected / {
         / partial iv / 6:h'61a7'
       },
       / ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
   3bd09abca'
     ]
   )

C.5.  Examples of MACed Messages

C.5.1.  Shared Secret Direct MAC

   This example uses the following:

   *  MAC: AES-CMAC, 256-bit key, truncated to 64 bits

   *  Recipient class: direct shared secret

   Size of binary file is 57 bytes

Schaad                   Expires 4 December 2020               [Page 77]
Internet-Draft               COSE Structure                    June 2020

   97(
     [
       / protected / h'a1010f' / {
           \ alg \ 1:15 \ AES-CBC-MAC-256//64 \
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / tag / h'9e1226ba1f81b848',
       / recipients / [
         [
           / protected / h'',
           / unprotected / {
             / alg / 1:-6 / direct /,
             / kid / 4:'our-secret'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

C.5.2.  ECDH Direct MAC

   This example uses the following:

   *  MAC: HMAC w/SHA-256, 256-bit key

   *  Recipient class: ECDH key agreement, two static keys, HKDF w/
      context structure

   Size of binary file is 214 bytes

Schaad                   Expires 4 December 2020               [Page 78]
Internet-Draft               COSE Structure                    June 2020

   97(
     [
       / protected / h'a10105' / {
           \ alg \ 1:5 \ HMAC 256//256 \
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
   4bc3f16a41',
       / recipients / [
         [
           / protected / h'a101381a' / {
               \ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
             } / ,
           / unprotected / {
             / static kid / -3:'peregrin.took@tuckborough.example',
             / kid / 4:'meriadoc.brandybuck@buckland.example',
             / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
   19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
   68b017e7f2a9e5ce4db5'
           },
           / ciphertext / h''
         ]
       ]
     ]
   )

C.5.3.  Wrapped MAC

   This example uses the following:

   *  MAC: AES-MAC, 128-bit key, truncated to 64 bits

   *  Recipient class: AES Key Wrap w/ a pre-shared 256-bit key

   Size of binary file is 109 bytes

Schaad                   Expires 4 December 2020               [Page 79]
Internet-Draft               COSE Structure                    June 2020

   97(
     [
       / protected / h'a1010e' / {
           \ alg \ 1:14 \ AES-CBC-MAC-128//64 \
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / tag / h'36f5afaf0bab5d43',
       / recipients / [
         [
           / protected / h'',
           / unprotected / {
             / alg / 1:-5 / A256KW /,
             / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
           },
           / ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
   b6eb0'
         ]
       ]
     ]
   )

C.5.4.  Multi-Recipient MACed Message

   This example uses the following:

   *  MAC: HMAC w/ SHA-256, 128-bit key

   *  Recipient class: Uses three different methods

      1.  ECDH Ephemeral-Static, Curve P-521, AES Key Wrap w/ 128-bit
          key

      2.  AES Key Wrap w/ 256-bit key

   Size of binary file is 309 bytes

Schaad                   Expires 4 December 2020               [Page 80]
Internet-Draft               COSE Structure                    June 2020

   97(
     [
       / protected / h'a10105' / {
           \ alg \ 1:5 \ HMAC 256//256 \
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
   1e49e9323e',
       / recipients / [
         [
           / protected / h'a101381c' / {
               \ alg \ 1:-29 \ ECHD-ES+A128KW \
             } / ,
           / unprotected / {
             / ephemeral / -1:{
               / kty / 1:2,
               / crv / -1:3,
               / x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
   71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
   d613574e7dc242f79c3',
               / y / -3:true
             },
             / kid / 4:'bilbo.baggins@hobbiton.example'
           },
           / ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
   a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
         ],
         [
           / protected / h'',
           / unprotected / {
             / alg / 1:-5 / A256KW /,
             / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
           },
           / ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
   518e7736549e998370695e6d6a83b4ae507bb'
         ]
       ]
     ]
   )

C.6.  Examples of MAC0 Messages

C.6.1.  Shared Secret Direct MAC

   This example uses the following:

   *  MAC: AES-CMAC, 256-bit key, truncated to 64 bits

Schaad                   Expires 4 December 2020               [Page 81]
Internet-Draft               COSE Structure                    June 2020

   *  Recipient class: direct shared secret

   Size of binary file is 37 bytes

   17(
     [
       / protected / h'a1010f' / {
           \ alg \ 1:15 \ AES-CBC-MAC-256//64 \
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / tag / h'726043745027214f'
     ]
   )

   Note that this example uses the same inputs as Appendix C.5.1.

C.7.  COSE Keys

C.7.1.  Public Keys

   This is an example of a COSE Key Set.  This example includes the
   public keys for all of the previous examples.

   In order the keys are:

   *  An EC key with a kid of "meriadoc.brandybuck@buckland.example"

   *  An EC key with a kid of "peregrin.took@tuckborough.example"

   *  An EC key with a kid of "bilbo.baggins@hobbiton.example"

   *  An EC key with a kid of "11"

   Size of binary file is 481 bytes

Schaad                   Expires 4 December 2020               [Page 82]
Internet-Draft               COSE Structure                    June 2020

   [
     {
       -1:1,
       -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
   8551d',
       -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
   4d19c',
       1:2,
       2:'meriadoc.brandybuck@buckland.example'
     },
     {
       -1:1,
       -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
   09eff',
       -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
   c117e',
       1:2,
       2:'11'
     },
     {
       -1:3,
       -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
   7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
   f42ad',
       -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
   60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
   d9475',
       1:2,
       2:'bilbo.baggins@hobbiton.example'
     },
     {
       -1:1,
       -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
   d6280',
       -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
   822bb',
       1:2,
       2:'peregrin.took@tuckborough.example'
     }
   ]

C.7.2.  Private Keys

   This is an example of a COSE Key Set.  This example includes the
   private keys for all of the previous examples.

   In order the keys are:

Schaad                   Expires 4 December 2020               [Page 83]
Internet-Draft               COSE Structure                    June 2020

   *  An EC key with a kid of "meriadoc.brandybuck@buckland.example"

   *  A shared-secret key with a kid of "our-secret"

   *  An EC key with a kid of "peregrin.took@tuckborough.example"

   *  A shared-secret key with a kid of "018c0ae5-4d9b-471b-
      bfd6-eef314bc7037"

   *  An EC key with a kid of "bilbo.baggins@hobbiton.example"

   *  An EC key with a kid of "11"

   Size of binary file is 816 bytes

   [
     {
       1:2,
       2:'meriadoc.brandybuck@buckland.example',
       -1:1,
       -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
   8551d',
       -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
   4d19c',
       -4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
   208cf'
     },
     {
       1:2,
       2:'11',
       -1:1,
       -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
   09eff',
       -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
   c117e',
       -4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
   7b4d3'
     },
     {
       1:2,
       2:'bilbo.baggins@hobbiton.example',
       -1:3,
       -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
   7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
   f42ad',
       -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
   60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
   d9475',

Schaad                   Expires 4 December 2020               [Page 84]
Internet-Draft               COSE Structure                    June 2020

       -4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
   55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
   eb26d'
     },
     {
       1:4,
       2:'our-secret',
       -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
   27188'
     },
     {
       1:2,
       -1:1,
       2:'peregrin.took@tuckborough.example',
       -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
   d6280',
       -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
   822bb',
       -4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
   df1c3'
     },
     {
       1:4,
       2:'our-secret2',
       -1:h'849b5786457c1491be3a76dcea6c4271'
     },
     {
       1:4,
       2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
       -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
   27188'
     }
   ]

Acknowledgments

   This document is a product of the COSE working group of the IETF.

   The following individuals are to blame for getting me started on this
   project in the first place: Richard Barnes, Matt Miller, and Martin
   Thomson.

   The initial version of the specification was based to some degree on
   the outputs of the JOSE and S/MIME working groups.

Schaad                   Expires 4 December 2020               [Page 85]
Internet-Draft               COSE Structure                    June 2020

   The following individuals provided input into the final form of the
   document: Carsten Bormann, John Bradley, Brain Campbell, Michael B.
   Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and Goran
   Selander.

Author's Address

   Jim Schaad
   August Cellars

   Email: ietf@augustcellars.com

Schaad                   Expires 4 December 2020               [Page 86]