Skip to content

Determine if CBOR map key sort order setting should be updated because RFC 9052 obsoleted RFC 8152 #110

@fxamacker

Description

@fxamacker

I used cbor.SortCanonical setting in mozilla-services/go-cose before RFC 8949 (CBOR) and RFC 9052 (COSE) were published. More recently,

  • RFC 8949 (CBOR) obsoleted RFC 7049 (CBOR).
  • RFC 9052 (COSE) obsoleted RFC 8152 (COSE).

RFC 8152 required Canonical encoding from RFC 7049, which uses length-first sort order for map keys.

RFC 9052 specifies, "The new encoding restrictions are aligned with the Core Deterministic Encoding Requirement" from RFC 8949. Additionally, the narrowed down requirements in RFC 9052 doesn't mention the old length-first sort order.

RFC 8949 specifies Core Deterministic Encoding Requirements with a newer sort order for map keys (bytewise lexicographic order of deterministic encoding).

RFC 8949 refers to the length-first-ordered version of "Canonical CBOR" specified in RFC 7049 as "Old Canonical CBOR".

Given this, go-cose can:

  • Use the newer sort order defined in RFC 8949 (CBOR) for Core Deterministic Encoding Requirements, or
  • Continue using length-first sort order from obsoleted RFC 7049, or
  • Maybe not sort map keys (for faster encoding speed at the cost of deterministic encoding).

For example, go-cose can specify cbor.SortCoreDeterministic here for map keys:

go-cose/cbor.go

Lines 30 to 33 in ac30917

encOpts := cbor.EncOptions{
Sort: cbor.SortCanonical, // sort map keys
IndefLength: cbor.IndefLengthForbidden, // no streaming
}

Just wanted to provide some context (not a recommendation to choose a specific sort).

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions