draft-ietf-cose-msg-21.txt   draft-ietf-cose-msg-22.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track October 16, 2016 Intended status: Standards Track October 16, 2016
Expires: April 19, 2017 Expires: April 19, 2017
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-21 draft-ietf-cose-msg-22
Abstract Abstract
Concise Binary Object Representation (CBOR) is data format designed Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size. There is a need for the for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
specification. This specification describes how to create and specification. This specification describes how to create and
process signature, message authentication codes and encryption using process signature, message authentication codes and encryption using
CBOR for serialization. This specification additionally specifies CBOR for serialization. This specification additionally specifies
skipping to change at page 14, line 4 skipping to change at page 14, line 4
located using the IANA "Media Types" registry. Applications located using the IANA "Media Types" registry. Applications
SHOULD provide this parameter if the content structure is SHOULD provide this parameter if the content structure is
potentially ambiguous. potentially ambiguous.
kid: This parameter identifies one piece of data that can be used as kid: This parameter identifies one piece of data that can be used as
input to find the needed cryptographic key. The value of this input to find the needed cryptographic key. The value of this
parameter can be matched against the 'kid' member in a COSE_Key parameter can be matched against the 'kid' member in a COSE_Key
structure. Other methods of key distribution can define an structure. Other methods of key distribution can define an
equivalent field to be matched. Applications MUST NOT assume that equivalent field to be matched. Applications MUST NOT assume that
'kid' values are unique. There may be more than one key with the 'kid' values are unique. There may be more than one key with the
same 'kid' value, so all of the keys may need to be checked to same 'kid' value, so all of the keys associated with this 'kid'
find the correct one. The internal structure of 'kid' values is may need to be checked. The internal structure of 'kid' values is
not defined and cannot be relied on by applications. Key not defined and cannot be relied on by applications. Key
identifier values are hints about which key to use. This is not a identifier values are hints about which key to use. This is not a
security critical field. For this reason, it can be placed in the security critical field. For this reason, it can be placed in the
unprotected headers bucket. unprotected headers bucket.
IV: This parameter holds the Initialization Vector (IV) value. For IV: This parameter holds the Initialization Vector (IV) value. For
some symmetric encryption algorithms this may be referred to as a some symmetric encryption algorithms this may be referred to as a
nonce. The IV can be placed in the unprotected header as nonce. The IV can be placed in the unprotected header as
modifying the IV will cause the decryption to yield plaintext that modifying the IV will cause the decryption to yield plaintext that
is readily detectable as garbled. is readily detectable as garbled.
skipping to change at page 21, line 42 skipping to change at page 21, line 42
1. Create a Sig_structure object and populate it with the 1. Create a Sig_structure object and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 14. byte string, using the encoding described in Section 14.
3. Call the signature verification algorithm passing in K (the key 3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used sign with), ToBeSigned
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, one must also In addition to performing the signature verification, the application
perform the appropriate checks to ensure that the key is correctly may also perform the appropriate checks to ensure that the key is
paired with the signing identity and that the signing identity is correctly paired with the signing identity and that the signing
authorized before performing actions. identity is authorized before performing actions.
4.5. Computing Counter Signatures 4.5. Computing Counter Signatures
Counter signatures provide a method of associating different Counter signatures provide a method of associating different
signature generated by different signers with some piece of content. signature generated by different signers with some piece of content.
This is normally used to provide a signature on a signature allowing This is normally used to provide a signature on a signature allowing
for a proof that a signature existed at a given time (i.e., a for a proof that a signature existed at a given time (i.e., a
Timestamp). In this document, we allow for counter signatures to Timestamp). In this document, we allow for counter signatures to
exist in a greater number of environments. As an example, it is exist in a greater number of environments. As an example, it is
possible to place a counter signature in the unprotected attributes possible to place a counter signature in the unprotected attributes
skipping to change at page 37, line 41 skipping to change at page 37, line 41
Signature algorithms are used with the COSE_Signature and COSE_Sign1 Signature algorithms are used with the COSE_Signature and COSE_Sign1
structures. At this time, only signatures with appendixes are structures. At this time, only signatures with appendixes are
defined for use with COSE, however considerable interest has been defined for use with COSE, however considerable interest has been
expressed in using a signature with message recovery algorithm due to expressed in using a signature with message recovery algorithm due to
the effective size reduction that is possible. Implementations will the effective size reduction that is possible. Implementations will
need to keep this in mind for later possible integration. need to keep this in mind for later possible integration.
8.1. ECDSA 8.1. ECDSA
ECDSA [DSS] defines a signature algorithm using ECC. ECDSA [DSS] defines a signature algorithm using ECC. Implementations
SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]. The use of a deterministic signature algorithms allows
for systems to avoid relying on random number generators in order to
avoid generating the same value of 'k' (the per-message random
value). Biased generation of the value be attacked and collisions
will lead to leaked keys. It additionally allows for doing
deterministic tests for the signature algorithm. The use of
deterministic ECDSA does not lessen the need to to have good random
number generation when creating the private key.
The ECDSA signature algorithm is parameterized with a hash function The ECDSA signature algorithm is parameterized with a hash function
(h). In the event that the length of the hash function output is (h). In the event that the length of the hash function output is
greater than the group of the key, the left-most bytes of the hash greater than the group of the key, the left-most bytes of the hash
output are used. output are used.
The algorithms defined in this document can be found in Table 5. The algorithms defined in this document can be found in Table 5.
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
| name | value | hash | description | | name | value | hash | description |
skipping to change at page 39, line 14 skipping to change at page 39, line 20
o If the 'key_ops' field is present, it MUST include 'verify' when o If the 'key_ops' field is present, it MUST include 'verify' when
verifying an ECDSA signature. verifying an ECDSA signature.
8.1.1. Security Considerations 8.1.1. Security Considerations
The security strength of the signature is no greater than the minimum The security strength of the signature is no greater than the minimum
of the security strength associated with the bit length of the key of the security strength associated with the bit length of the key
and the security strength of the hash function. and the security strength of the hash function.
Systems that have poor random number generation can leak their keys
by signing two different messages with the same value 'k' (the per-
message random value). [RFC6979] provides a method to deal with this
problem by making 'k' be deterministic based on the message content
rather than randomly generated. Applications that specify ECDSA
should evaluate the ability to get good random number generation and
require deterministic signatures where poor random number generation
exists.
Note: Use of this technique is a good idea even when good random Note: Use of this technique is a good idea even when good random
number generation exists. Doing so both reduces the possibility of number generation exists. Doing so both reduces the possibility of
having the same value of 'k' in two signature operations and allows having the same value of 'k' in two signature operations and allows
for reproducible signature values, which helps testing. for reproducible signature values, which helps testing.
There are two substitution attacks that can theoretically be mounted There are two substitution attacks that can theoretically be mounted
against the ECDSA signature algorithm. against the ECDSA signature algorithm.
o Changing the curve used to validate the signature: If one changes o Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one the curve used to validate the signature, then potentially one
 End of changes. 5 change blocks. 
17 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/