Draft: draft-ietf-cose-msg

Commentary: Change tag number change media types
Constrained Application Protocol (CoAP) is a specialized web transfer
protocol for use in constrained systems.  It is defined in RFC7252.
When a COSE object is carried in a media type of application/cose,
the optional parameter 'cose-type' can be used to identify the
embedded object.  The parameter is OPTIONAL if the tagged version
of the structure is used.  The parameter is REQUIRED if the
untagged version of the structure is used.  The value to use with
the parameter for each of the structures can be found in CBOR-
Tags.
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be present at each level
of a signed, encrypted or authenticated message.  This parameter
MUST be in the protected header bucket.  The value is taken from
the 'COSE Algorithm Registry' (see cose-algorithm-registry).
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be present at each level
of a signed, encrypted or authenticated message.  When the
algorithm supports authenticating extenral data, this parameter
MUST be in the protected header bucket.  The value is taken from
the 'COSE Algorithm Registry' (see cose-algorithm-registry).
This parameter is used to indicate the content type of the data in
the payload or ciphertext fields.  Integers are from the 'CoAP
Content-Formats' IANA registry table.  [CREF3] Strings are from
the IANA 'Media Types' registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
This parameter is used to indicate the content type of the data in
the payload or ciphertext fields.  Integers are from the 'CoAP
Content-Formats' IANA registry table.  Strings are from the IANA
'Media Types' registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  The
IV used for the cryptographic computation is constructed by
concatenating the fixed portion of the IV and the changing portion
of the IV.  (The partial IV being treated as a network order
integer converted to a four byte string for this purpose.)  As the
IV is authenticated by the encryption process, this value can be
placed in the unprotected header bucket.
Some applications may also use this value for doing replay
protection.  When this is done, the value will normally be defined
by the application to be increasing in value for every message.
Encoding it as an integer value makes it easier to do this
comparison.
This parameter holds a counter signature value.  Counter
signatures provide a method of having a second party sign some
data.  The counter signature can occur as an unprotected attribute
in any of the following structures: COSE_Sign, COSE_signature,
COSE_Enveloped, COSE_recipient, COSE_Encrypted, COSE_mac.  These
structures all have the same basic structure so that a consistent
calculation of the counter signature can be computed.  Details on
computing counter signatures are found in counter_signature.
This parameter provides the time the content cryptographic
operation is performed.  For signatures and recipient structures,
this would be the time that the signature or recipient key object
was created.  For content structures, this would be the time that
the content structure was created.  The unsigned integer value is
the number of seconds, excluding leap seconds; after midnight UTC,
January 1, 1970.  The field is primarily intended to be to be used
for countersignatures, however it can additionally be used for
replay detection as well.
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  As
the IV is authenticated by the encryption process, this value can
be placed in the unprotected header bucket.
The final IV is generated by concatenating the fixed portion of
the IV, a zero string and the changing portion of the IV.  The
length of the zero string is computed by taking the required IV
length and subtracting the lengths of the fixed and changing IV
portions.
This parameter holds a counter signature value.  Counter
signatures provide a method of having a second party sign some
data.  The counter signature can occur as an unprotected attribute
in any of the following structures: COSE_Sign, COSE_Sign1,
COSE_Signature, COSE_Enveloped, COSE_recipient, COSE_Encrypted,
COSE_Mac and COSE_Mac0.  These structures all have the same basic
structure so that a consistent calculation of the counter
signature can be computed.  Details on computing counter
signatures are found in counter_signature.
This parameter provides the time the content cryptographic
operation is performed.  For signatures and recipient structures,
this would be the time that the signature or recipient key object
was created.  For content structures, this would be the time that
the content structure was created.  The unsigned integer value is
the number of seconds, excluding leap seconds, after midnight UTC,
January 1, 1970.  The field is primarily intended to be to be used
for countersignatures, however it can additionally be used for
replay detection as well.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  [CREF4] Examples
of parameters about the signature would be the algorithm and key used
to create the signature, when the signature was created, and counter-
signatures.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  [CREF3] Examples
of parameters about the signature would be the algorithm and key used
to create the signature, when the signature was created, and counter-
signatures.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message structure RFC7252 where the
facility exists for options to be carried before the payload.
[CREF5] An example of data that can be placed in this location would
be transaction ids and nonces to check for replay protection.  If the
data is in the options section, then it is available for routers to
help in performing the replay detection and prevention.  However, it
may also be desired to protect these values so that they cannot be
modified in transit.  This is the purpose of the externally supplied
data field.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message structure RFC7252 where the
facility exists for options to be carried before the payload.  An
example of data that can be placed in this location would be CoAP
options for transaction ids and nonces to check for replay
protection.  If the data is in the options section, then it is
available for routers to help in performing the replay detection and
prevention.  However, it may also be desired to protect these values
so that they cannot be modified in transit.  This is the purpose of
the externally supplied data field.
Key Wrap algorithm: The key wrap algorithm can be 'none' if the
result of the KDF is going to be used as the key directly.  This
option, along with static-static, should be used if knowledge
about the sender is desired.  If 'none' is used, then the content
layer encryption algorithm size is value fed to the context
structure.  Support is also provided for any of the key wrap
algorithms defined in key_wrap_algs.  If one of these options is
used, the input key size to the key wrap algorithm is the value
fed into the context structure as the key size.
Key Wrap algorithm: A key wrap algorithm of 'none' means that the
result of the KDF is going to be used as the key directly.  This
option, along with static-static, should be used if knowledge
about the sender is desired.  If 'none' is used, then the content
layer encryption algorithm size is value fed to the context
structure.  Support is also provided for any of the key wrap
algorithms defined in key_wrap_algs.  If one of these options is
used, the input key size to the key wrap algorithm is the value
fed into the context structure as the key size.
The tags to be assigned are in table CBOR-Tags.
This section registers the "application/cose" media type in the
"Media Types" registry.  These media types are used to indicate that
the content is a COSE_MSG.
Security considerations: See the Security Considerations section
of RFC TBD.