On 2025-10-10 16:28, Phillip Hallam-Baker wrote:
Carsten is completely right about this. The problem is with the nested varints.
You can't start writing out the enclosing structure until you know the length
of the inner structures.
The nested construction is also a security hazzard, there are plenty of
exploits that involve internal objects that overrun the enclosing length. There
are occasions when this is actually necessary and useful, DER encoding is not
one of them.
The problem with DER are deeper though in that the original 'specification' is
really not much more than an offhand comment in the spec, a paragraph that says
DER encoding is BER but always using the definite length encoding. There are no
examples and it does not even consider the encoding of SET OF. That came later
after someone realized that the 'canonical' encoding was not.
The history here appears to be that that someone had the idea of taking X.509
certificates, stripping them apart, storing the results in an X.500 directory
and then reassembling them during a meeting, they came up with DER over a long
lunch and dropped it into the spec before anyone tried implementing it.
If you want digital signatures to work reliably, absolutely the only way to do
that in practice is to ensure that you give the actual sequence of octets you
signed to the party verifying. To attempt anything else is to be in a state of
sin.
Oddly enough, Carsten & Co are currently developing the CBOR equivalent to DER (CDE), but
they don't believe it is suitable for signing/hashing purposes. "bstr" rulez!
Personally, I find the combination deterministically encoded CBOR and
signatures working as a charm:
https://test.webpki.org/csf-lab/home
Anders
On Fri, Oct 10, 2025 at 2:58 AM Carsten Bormann <[email protected]
<mailto:[email protected]>> wrote:
On Oct 10, 2025, at 04:36, Laurence Lundblade <[email protected]
<mailto:[email protected]>> wrote:
>
>
>> On Oct 9, 2025, at 12:46 PM, Phillip Hallam-Baker <[email protected]
<mailto:[email protected]>> wrote:
>>
>> I wrote nested varints. Gmail overrode me.
>>
>> The problem is that you can't DER encode an object in a single forward
pass because you can't write the outermost object until its length is known and you
don't know that till you have the lengths of the inner objects and so on.
>
> Right. Same for CBOR deterministic encoding.
There is a *big* difference, though:
DER needs lengths in bytes, so it needs to know the encoded byte lengths of
all data items inside the one to be DER-encoded, which practically means you
have to encode bottom-up.
In CBOR, we only count bytes at the leaves (byte/text strings); otherwise
we count whole child data items *at that node* (arrays, maps).
The number of data items (array elements, key/value items in map entries)
in a container generally is available to an implementation (*) *before* having
done the encoding for all the data items in the container.
We now know that an encoding scheme that requires byte lengths to match up
hierarchically throughout an encoding tree is a recipe for constantly creating
implementation vulnerabilities.
Don’t do that.
Obviously, embedded CBOR (byte strings that contain encoded CBOR data
items) do require the byte string length of the embedded byte string to match
up with the length of the embedded data item (as determined by its
self-delimiting nature).
This is much less of a problem than for DER, which has nested, redundant
byte lengths everywhere, because protocol designers will use embedded CBOR
where it is actually natural to process the embedded item before doing the
encoding of the enclosing item.
Grüße, Carsten
(*) Except for a streaming encoder, which is incompatible with the way we
have defined common deterministic encoding (CDE), mostly because there is no
way to do the required map sorting in a streaming encoder in general.
_______________________________________________
COSE mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
COSE 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]
