On 2022-03-08 18:07, Laurence Lundblade wrote:
Hi Laurence,
This is just a PoC with the aim showing that the scheme I'm advocating is
simple.
I'm sure CBOR tool designers can implement something fitting (if they feel a
need).
In my Java implementation, the read-and-delete operation requires TWO lines of
code. That is some 1000-5000 times times less than a full-blown XML transform.
This is another, related topic:
https://github.com/cyberphone/D-CBOR/blob/main/d-cbor-4-constrained-devices.md#handling-indefinite-length-data
Cheers,
Anders
On Mar 7, 2022, at 9:23 PM, Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
On 2022-03-04 8:08, Carsten Bormann wrote:
On 2022-03-04, at 07:54, Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
- Collect key and algorithm data from the authorization signature object.
- Save and Remove FIDO "authenticatorData" and FIDO "signature" from the CBOR
container.
This is what we called the “transform” in the beloved XMLDSig.
The complexities of this step can be the basis of interesting vulnerabilities
(or interoperability failures).
Since I had not worked with low-level encoders and decoders, I spent a couple
of days in the lab (kitchen actually).
To not be dependent on my own stuff (which of course works flawlessly since it
was from the beginning designed with FIDO in mind), I applied the more
universal CSF (CBOR Signature Format) to Laurence's excellent QCBOR library.
This is what I came up with:
https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c
<https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c>
Your code accesses private QCBOR data structures to make this work, but no fear
because 1) this part of QCBOR is not going to change and 2) I’m working on a PR to
allow access to encoded maps and arrays
<https://github.com/laurencelundblade/QCBOR/pull/117>. (I’m bit bogged down on
QCBOR PRs these days)
The actual transform part is performed by FOUR LINES of C. This was a surprise
even to me.
Carsten, you should be proud; CBOR is the by far best data interchange format
for blending with cool cryptographic constructs!
Could wrapping your precious data in bstr just in order to sign it, be headed
for obsolescence? :)
I suspect not because decoders in other languages won’t be so easy to modify
for this.
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose