> On Dec 15, 2020, at 8:53 AM, Carsten Bormann <[email protected]> wrote: > > On 2020-12-07, at 23:02, Laurence Lundblade <[email protected]> wrote: >> >> I don’t think it works very well at all to directly sign encoded CBOR. It >> should be wrapped in a byte string. > > Sorry for coming in late; I’m having a hard time following this thread. > > Generally, we don’t want to do the “XMLDsig” thing and require canonical (the > new word is “deterministic” in RFC 8949) encoding of CBOR data items > re-encoded as signature input. > > But it seems to me that the structure described on page 8 of > draft-mattsson-cose-cbor-cert-compress-05.txt doesn’t need that: > > https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05#page-8 > > This is a CBOR sequence (RFC 8742) of 11 CBOR data items, 10 of which form a > subsequence that would be the signing input, and the 11th being a byte string > with the signature. > I’m not sure the current draft defines how to do that for native signing, and > I hope the procedure will be culturally compatible with COSE at some point > (i.e., facilitate some code reuse/sharing). > > RFC 8949 does not prescribe an API for a generic CBOR decoder. But we can go > by the 60+ implementations documented on https://cbor.io/impls.html — > generally these do not provide ways to decode an encoded data item and then > ask the decoder for the position and length of a specific subtree in the > encoded input. I think this is what Laurence has in mind.
Yes, you need the offset of the end of the to-be-hashed data returned by the CBOR decoder (or some equivalent way of knowing what to hash). I wouldn’t expect CBOR decoders to return this offset as it doesn’t seem necessary for anything but this particularly use case, not even for COSE. > But the situation here is somewhat different: The top level of a > X.509-compatible CBOR certificate is that sequence. Many CBOR > implementations do not address CBOR sequences (RFC 8742) explicitly, they > just allow you to decode an item from a start position and give you the end > position. Applying that 10 times gives you an end position that can be used > with the start of the encoded certificate as the extent of the signing input. > The result of signing that can then be compared with the content of the 11th > item. > > So I think that we do not have the same level of problem we would have if we > needed to obtain start/end positions for something deep in the structure. I agree that this is not the same level of problem because the start position is 0 and the end position is not as hard to find as in COSE. But it still seems like a problem that may require change to many otherwise complete CBOR decoders. My decoder, QCBOR, works on sequence but doesn’t return offsets.. Some other decoder might process the CBOR into an internal tree structure first and not record the offsets and thus not be able to return them. When I spoke of hacking the decoder previously, it was modifications to know the offset. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
