Draft: draft-schaad-cose-msg

Commentary: Change the document name as is now adopted Move the location of the section " CBOR Encoder Restrictions " Fix some references for EC points . Change how example text is laid out Add section on document updates
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at https://github.com/
cose-wg/cose-spec.  Instructions are on that page as well.  Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the COSE mailing list.
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
cose-wg/cose-spec>.  Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial
issues need to be discussed on the COSE mailing list.
This field is used to indicate the content type of the data in the
payload or ciphertext fields.  The field uses the integer of '3'
for the label.  The value can be either an integer or a string.
Integers are from the XXXXX[CREF6] IANA registry table.  Strings
are from the IANA 'mime-content types' registry.  Applications
SHOULD provide this field if the content structure is potentially
ambiguous.
This field is used to indicate the content type of the data in the
payload or ciphertext fields.  The field uses the integer of '3'
for the label.  The value can be either an integer or a string.
[CREF6] Integers are from the XXXXX[CREF7] IANA registry table.
Strings are from the IANA 'mime-content types' registry.
Applications SHOULD provide this field if the content structure is
potentially ambiguous.
In this section we describe the structure and methods to be used when
doing MAC authentication in COSE.  JOSE used a variant of the
signature structure for doing MAC operations and it is restricted to
using a single pre-shared secret to do the authentication.  [CREF8]
This document allows for the use of all of the same methods of key
management as are allowed for encryption.
In this section we describe the structure and methods to be used when
doing MAC authentication in COSE.  JOSE used a variant of the
signature structure for doing MAC operations and it is restricted to
using a single pre-shared secret to do the authentication.  [CREF9]
This document allows for the use of all of the same methods of key
management as are allowed for encryption.
This contains a one time nonce value.  The nonce can either be
implicit from the protocol or carried as a value in the
unprotected headers.  [CREF12]
We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message However, the nonce
value could be determined by the application and the value
determined from elsewhere.
This item is optional and can be absent.
This contains a one time nonce value.  The nonce can either be
implicit from the protocol or carried as a value in the
unprotected headers.  [CREF13]
We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message However, the nonce
value could be determined by the application and the value
determined from elsewhere.
This item is optional and can be absent.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  [CREF13] When direct encryption mode
is used, it MUST be the only mode used on the message.  It is a
massive security leak to have both direct encryption and a different
key management mode on the same message.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  [CREF14] When direct encryption mode
is used, it MUST be the only mode used on the message.  It is a
massive security leak to have both direct encryption and a different
key management mode on the same message.
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64-bits, as
such it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  [CREF14] The algorithm requires
a single fixed parameter, the initial value.  This is fixed to the
value specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64-bits, as
such it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  [CREF15] The algorithm requires
a single fixed parameter, the initial value.  This is fixed to the
value specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
It is highly recommended that checks on the key length be done before
starting a decryption operation.  One potential denial of service
operation is to provide encrypted objects using either abnormally
long or oddly sized RSA modulus values.  Implementations SHOULD be
able to encrypt and decrypt with modulus between 2048 and 16K bits in
length.[CREF15] Applications can impose additional restrictions on
the length of the modulus.
It is highly recommended that checks on the key length be done before
starting a decryption operation.  One potential denial of service
operation is to provide encrypted objects using either abnormally
long or oddly sized RSA modulus values.  Implementations SHOULD be
able to encrypt and decrypt with modulus between 2048 and 16K bits in
length.[CREF16] Applications can impose additional restrictions on
the length of the modulus.
Two different key structures are being defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in [EC-in-PKIX].  The other version uses
only the x coordinate as the y coordinate is either to be recomputed
or not needed for the key agreement operation.  An example of this is
[Curve25519].
Two different key structures are being defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in RFC5480.  The other version uses only
the x coordinate as the y coordinate is either to be recomputed or
not needed for the key agreement operation.  An example of this is
Curve25519 I-D.irtf-cfrg-curves.
contains an identifier of the curve to be used with the key.
[CREF20] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
contains an identifier of the curve to be used with the key.
[CREF21] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF24] These
media types are used to indicate that the content is a COSE_MSG.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF25] These
media types are used to indicate that the content is a COSE_MSG.