Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt

Unlike JSON which nowadays [1] have a working deterministic representation [2], CBOR leaves a good portion of this crucial part to application developers to figure out.
The net result is a fragmented CBOR space with groups like FIDO creating their own unique definition called CTAP2.

The authors will consider the ISE path for the proposed work-item.

thanx,
Anders

1] Encountered floating point parsing and serialization issues have been fixed by the platform vendors which makes the task creating an RFC 8785-compatible canonicalizer quite simple.
2] By constraining the Number type to IEEE 754 double and requiring the String type to be immutable.

On 2021-07-27 3:23, Carsten Bormann wrote:
>> As I understood Carsten's suggestion, we should canonicalize the data by
>> turning it into CBOR, and using COSE.
> 
> Actually, when I started saying that, I meant it as a reduction ad absurdum.
> 
> But after thinking about it, it is actually not so absurd, but the best way to handle the use case — everything is already in place for that.
> 
> But that simple change is just a different function to compute a signing input from data at rest — the more difficult question is what is it that you compute the signing input of, and the fact that you now have a signature for something that is in a complex and not entirely well-defined relationship to the data that is in your database and that you might think some subset of which you maybe have a signature for.
> 
> If your application design can take care of that part, then you win (and can use CBOR-deterministic + COSE, or if you must, translate to XML first and do an XMLDsig, etc.).
> 
> Grüße, Carsten
> 
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
> 