search

ietf-rats / ietf-corim-cddl

This repository is abandoned. The adopted I-D can be found at:
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/
2 stars 0 forks source link

How to handle endianness #61

Closed nedmsmith closed 3 years ago

nedmsmith commented 3 years ago

The current convention for endianness seems workable for reference measurements (aka 'vendor' decides endianness and constructs both tag and evidence such that verifier doesn't care about endianness). However, for endorsed claims and instance claims verifier might need to know endianness semantics. For example, if a policy expects to inspect specific element-name / element-value / etc... values against values specified in a policy, then the verifier will need to understand endianness.

One option is to encode endianness into the data set.

Another option is to declare the endianness convention for each attribute in a spec.

Other options?

nedmsmith commented 3 years ago

Someone thought CBOR defines endianness in all cases. Is this true?

thomas-fossati commented 3 years ago

Someone thought CBOR defines endianness in all cases. Is this true?

https://www.rfc-editor.org/rfc/rfc8949.html#section-1.2-2

nedmsmith commented 3 years ago

Is JSON aligned similarly?

In other words can someone reading CDDL be unambiguous about endianness regardless of which encoding is selected (JSON/CBOR)?

thomas-fossati commented 3 years ago

Is JSON aligned similarly? In other words can someone reading CDDL be unambiguous about endianness regardless of which encoding is selected (JSON/CBOR)?

https://datatracker.ietf.org/doc/html/rfc8259#section-8.1 first para: UTF-8 is a MUST so there is no ambiguity.

nedmsmith commented 3 years ago

For all practical purposes, then, CDDL is big-endian?

thomas-fossati commented 3 years ago

For all practical purposes, then, CDDL is big-endian?

yes