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. On Fri, Oct 10, 2025 at 2:58 AM Carsten Bormann <[email protected]> wrote: > On Oct 10, 2025, at 04:36, Laurence Lundblade <[email protected]> > wrote: > > > > > >> On Oct 9, 2025, at 12:46 PM, Phillip Hallam-Baker <[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] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
