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.

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.

Grüße, Carsten

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to