Draft: draft-schaad-cose-msg

Commentary: Nits discovered by   during a review of draft - schaad - cose - msg-01 . This branch includes grammar and spelling corrections . Most of the grammar corrections are changing instances of " which " to " that " , where appropriate . I also changed uses of the term " byte " to " octet " . 
 Please revert the change from byte to octet . 
 I reverted the change from " byte " from " octet " . I left the word " octet " in SEC1 contexts , since that 's the term that it uses .
Define a top level message structure so that encrypted, signed and
MAC-ed messages can easily identified and still have a consistent
view.
Define a top level message structure so that encrypted, signed and
MACed messages can easily identified and still have a consistent
view.
The COSE_MSG structure is a top level CBOR object which corresponds
to the DataContent type in the Cryptographic Message Syntax (CMS)
RFC5652.  This structure allows for a top level message to be sent
which could be any of the different security services.  The security
service is identified within the message.
The COSE_MSG structure is a top level CBOR object that corresponds to
the DataContent type in the Cryptographic Message Syntax (CMS)
RFC5652.  This structure allows for a top level message to be sent
that could be any of the different security services.  The security
service is identified within the message.
Implementations MUST be prepared to find an integer under this label
which does not correspond to the values 1 to 3.  If this is found
then the client MUST stop attempting to parse the structure and fail.
The value of 0 is reserved and not to be used.  If the value of 0 is
found, then clients MUST fail processing the structure.
Implementations need to recognize that the set of values might be
extended at a later date, but they should not provide a security
service based on guesses of what is there.
Implementations MUST be prepared to find an integer under this label
that does not correspond to the values 1 to 3.  If this is found then
the client MUST stop attempting to parse the structure and fail.  The
value of 0 is reserved and not to be used.  If the value of 0 is
found, then clients MUST fail processing the structure.
Implementations need to recognize that the set of values might be
extended at a later date, but they should not provide a security
service based on guesses of what is there.
contains attributes about the layer which are to be
cryptographically protected.  This bucket MUST NOT be used if it
is not going to be included in a cryptographic computation.
contains attributes about the layer which are not
cryptographically protected.
contains attributes about the layer that are to be
cryptographically protected.  This bucket MUST NOT be used if it
is not going to be included in a cryptographic computation.
contains attributes about the layer that are not cryptographically
protected.
This field is used to ensure that applications will take
appropriate action based on the values found.  The field is used
to indicate which protected header labels an application which is
processing a message is required to understand.  This field uses
the integer '2' for the label.  The value is an array of COSE
Header Labels.  When present, this MUST be placed in the protected
header bucket.
This field is used to ensure that applications will take
appropriate action based on the values found.  The field is used
to indicate which protected header labels an application that is
processing a message is required to understand.  This field uses
the integer '2' for the label.  The value is an array of COSE
Header Labels.  When present, this MUST be placed in the protected
header bucket.
contains attributes about the payload which are to be protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  The content is a CBOR map of
attributes which is encoded to a byte stream.  This field MUST NOT
contain attributes about the signature, even if those attributes
are common across multiple signatures.  The labels in this map are
typically taken from Header-Table.
contains attributes about the payload which are not protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  This field MUST NOT contain
attributes about a signature, even if the attributes are common
across multiple signatures.  The labels in this map are typically
taken from Header-Table.
contains attributes about the payload that are to be protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  The content is a CBOR map of
attributes that is encoded to a byte stream.  This field MUST NOT
contain attributes about the signature, even if those attributes
are common across multiple signatures.  The labels in this map are
typically taken from Header-Table.
contains attributes about the payload that are not protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  This field MUST NOT contain
attributes about a signature, even if the attributes are common
across multiple signatures.  The labels in this map are typically
taken from Header-Table.
contains the serialized content to be signed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes, if the payload is
transported separately it is the responsibility of the application
to ensure that it will be transported without changes.
contains the serialized content to be signed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes.  If the payload is
transported separately, it is the responsibility of the
application to ensure that it will be transported without changes.
contains additional information to be authenticated by the
signature.  The field holds data about the signature operation.
The field MUST NOT hold attributes about the payload being signed.
The content is a CBOR map of attributes which is encoded to a byte
stream.  At least one of protected and unprotected MUST be
present.
contains attributes about the signature which are not protected by
the signature.  This field MUST NOT contain attributes about the
payload being signed.  At least one of protected and unprotected
MUST be present.
contains additional information to be authenticated by the
signature.  The field holds data about the signature operation.
The field MUST NOT hold attributes about the payload being signed.
The content is a CBOR map of attributes that is encoded to a byte
stream.  At least one of protected and unprotected MUST be
present.
contains attributes about the signature that are not protected by
the signature.  This field MUST NOT contain attributes about the
payload being signed.  At least one of protected and unprotected
MUST be present.
In addition to performing the signature verification, one must also
perform the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the appropriated
authorization is done.
In addition to performing the signature verification, one must also
perform the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the appropriate
authorization is done.
contains attributes about the payload which are to be protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  The content is a CBOR map of attributes
which is encoded to a byte stream.  This field MUST NOT contain
attributes about the recipient, even if those attributes are
common across multiple recipients.  At least one of protected and
unprotected MUST be present.
contains attributes about the payload which are not protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  This field MUST NOT contain attributes
about a recipient, even if the attributes are common across
multiple recipients.  At least one of protected and unprotected
MUST be present.
contains the serialized content to be MAC-ed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes, if the payload is
transported separately it is the responsibility of the application
to ensure that it will be transported without changes.
contains attributes about the payload that are to be protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  The content is a CBOR map of attributes
that is encoded to a byte stream.  This field MUST NOT contain
attributes about the recipient, even if those attributes are
common across multiple recipients.  At least one of protected and
unprotected MUST be present.
contains attributes about the payload that are not protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  This field MUST NOT contain attributes
about a recipient, even if the attributes are common across
multiple recipients.  At least one of protected and unprotected
MUST be present.
contains the serialized content to be MACed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes, if the payload is
transported separately it is the responsibility of the application
to ensure that it will be transported without changes.
There are only a few changes between JOSE and COSE for how keys are
formatted.  As with JOSE, COSE uses a map to contain the elements of
a key.  Those values, which in JOSE, are base64url encoded because
they are binary values, are encoded as bstr values in COSE.
There are only a few changes between JOSE and COSE for how keys are
formatted.  As with JOSE, COSE uses a map to contain the elements of
a key.  Those values, which in JOSE are base64url encoded because
they are binary values, are encoded as bstr values in COSE.
Any item which is base64 encoded in JWK, is bstr encoded for COSE.
Any item which is integer encoded in JWK, is int encoded for COSE.
Any item which is string (but not base64) encoded in JWK, is tstr
encoded for COSE.
Any item that is base64url encoded in JWK, is bstr encoded for
COSE.
Any item that is integer encoded in JWK, is int encoded for COSE.
Any item that is string (but not base64url) encoded in JWK, is
tstr encoded for COSE.
limits messages to 2^16 bytes in length.  The nonce length is 13
octets allowing for 2^(13*8) possible values of the nonce without
repeating.
limits messages to 2^64 byes in length.  The nonce length is 7
octets allowing for 2^56 possible values of the nonce without
repeating.
limits messages to 2^16 bytes in length.  The nonce length is 13
bytes allowing for 2^(13*8) possible values of the nonce without
repeating.
limits messages to 2^64 byes in length.  The nonce length is 7
bytes allowing for 2^56 possible values of the nonce without
repeating.
length - the number of octets of output that need to be generated.
length - the number of bytes of output that need to be generated.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in RFC7518 were
extended to allow for authenticated data.  In that event the use of
the 'protected' field, which is current forbidden below, would be
permitted.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in RFC7518 were
extended to allow for authenticated data.  In that event, the use of
the 'protected' field, which is current forbidden below, would be
permitted.
For JOSE, direct encryption key management is the only key management
method allowed for doing MAC-ed messages.  In COSE, all of the key
management methods can be used for MAC-ed messages.
For JOSE, direct encryption key management is the only key management
method allowed for doing MACed messages.  In COSE, all of the key
management methods can be used for MACed messages.
The label is to be unique for every value of key type.  The range
of values is from -256 to -1.  Labels are expected to be re-used
for different keys.
The label is to be unique for every value of key type.  The range
of values is from -256 to -1.  Labels are expected to be reused
for different keys.
This section registers the "application/cose+json" and "application/
cose-set+json" media typesin the "Media Types" registry.  These media
types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object.
This section registers the "application/cose+json" and "application/
cose-set+json" media types in the "Media Types" registry.  These
media types are used to indicate, respectively, that content is a
COSE_Key or COSE_KeySet object.