> On Mar 7, 2022, at 9:23 PM, Anders Rundgren <anders.rundgren....@gmail.com>
> wrote:
>
> On 2022-03-04 8:08, Carsten Bormann wrote:
>> On 2022-03-04, at 07:54, Anders Rundgren <anders.rundgren....@gmail.com>
>> 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
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
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
