search

cose-wg / cose-issues

COSE Working Group Issues
0 stars 1 forks source link

Move “sequence number” value to the payload #14

Closed selfissued closed 8 years ago

selfissued commented 8 years ago

Like “creation time”, the “sequence number” header parameter defined in Section 3.1 is a non-cryptographic application-defined attribute, and so should be defined in a companion CBOR payload definitions specification, if at all. Only cryptographic-relevant header parameters should be defined by COSE. The text “The use of this parameter is application specific” is the giveaway that this doesn’t belong here.

sandy7de commented 8 years ago

"Sequence number" may be an wrong term which incorrectly associates it to the payload. The correct term would be nonce_explicit like in RFC6655. The implicit part of the nonce (referred as salt in RFC6655 is known to the parties based on the context cid). Additional constraint being that nonce_explicit is an increasing counter value. Applications or any other token format can use the nonce_explicit to perform replay protection. This prevents unnecessary duplication of a same value required for two purposes (nonce for AEAD and counter sequence number for replay protection).

jimsch commented 8 years ago

Renamed the field to be "partial IV" and describe better how it would be used. Make the replay protection aspects of the field to be very secondary.