On 2025-04-14 07:11, Carsten Bormann wrote:
Hi Mike,
On 14. Apr 2025, at 02:47, Michael Jones <[email protected]> wrote:
I agree with Orie's and Mike P.'s earlier comments. We should steer completely
clear of any form of canonicalization, because of the complications and interop
problems that it causes.
This went to both CBOR and COSE, so my question is: Who is “we”?
For COSE, I’d probably agree with the general sentiment, but not because of
deterministic encoding.
(COSE does use a form of deterministic encoding [1] to derive its
signing/MACing inputs, but here we got a choice to design the input so that
becomes totally non-problematic.
COSE key thumbprint uses a more complete of deterministic encoding constraints
[2]; we should not have done that if we’d be following your rule.)
For CBOR, certainly not.
A good approach to deterministic encoding has been part of CBOR from the start.
(If you are serious about doing something that requires deterministic encoding,
CBOR is a rather good choice, without introducing the problems that plague the
text-based data representation formats.)
Embedded signatures require more than deterministic encoding (and, strictly
speaking, not even that):
They require transforms for embedding and then erasing the signature(s), and that’s
where there are “interesting" problems.
Signing (or digesting!) data at rest requires a good dose of ALDR rules plus
deterministic encoding to derive the signing/digesting inputs from the data at
rest; CBOR has the deterministic encoding covered for you if you want to tackle
that problem area [and you may never need to see actual CBOR-encoded data on
the wire].
There are plenty of documents related to Verified Credentials showing the use
of embedded signatures, some of them using my JSON Canonicalization Scheme (RFC
8785).
I have now turned to CBOR and deterministic encoding, which based on my (rather
extensive) work, proved to be much simpler and free from the quirks introduced
by JSON's poor numeric model.
However, it is true that a deterministic encoding format alone is insufficient
in order to support embedded signatures.
What the CBOR community seems to disagree on is what is required by
decoders/encoders and applications. I have addressed this through Object
Oriented methods and Encapsulation, techniques that have been in use since
decades back to deal with ASN.1 DER encoding:
https://www.ietf.org/archive/id/draft-rundgren-cbor-core-04.html#name-enveloped-signatures
Using this concept, even notoriously difficult items like ISO date/time
objects, pass (bidirectionally) without hitch:
https://cyberphone.github.io/CBOR.js/doc/#main.time
For those who still are curious, why not take a stab at
https://cyberphone.github.io/doc/defensive-publications/partial-encryption-full-signature.pdf
and see what a COSE-based counterpart would entail?
Embedded signatures are here to stay.
Says,
Anders
Grüße, Carsten
[1]: https://www.rfc-editor.org/rfc/rfc9052#name-cbor-encoding-restrictions
[2]: https://www.rfc-editor.org/rfc/rfc9679.html#name-cose-key-thumbprint
_______________________________________________
CBOR mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
