Anders, Sure, I think either would be helpful to separate the "transport of C509" from "decode/inspect the C509". A similar discussion [1] was had in the DTN WG about bstr-embedding of other data for similar reasons, but hasn't yet reached a conclusion. In the case of [1] the container array size was fixed so provided no information. For C509 a definite array size at least can inform a decoder about how many extensions are present before decoding them, but in practice I don't know how valuable that is for implementations to have.
[1] https://mailarchive.ietf.org/arch/msg/dtn/mmfQGd8K2W2PaH02RJDPIMMl52g/ > -----Original Message----- > From: Carsten Bormann <[email protected]> > Sent: Friday, March 14, 2025 1:25 PM > To: Anders Rundgren <[email protected]> > Cc: Sipos, Brian J. <[email protected]>; Göran Selander > <[email protected]>; [email protected] > Subject: Re: [COSE] [EXT] I-D Action: draft-ietf-cose-cbor-encoded-cert-13.txt > > APL external email warning: Verify sender [email protected] before clicking links > or > attachments > > On 2025-03-14, at 18:11, Anders Rundgren <[email protected]> > wrote: > > > > bstr(~C509Certificate) > > I don’t know which notation this is supposed to be, but unwrapping a > C509Certificate in CDDL as in ~C509Certificate creates a group. > Is the intention maybe > > bstr .cborseq C509Certificate > > ? > > (Which saves one byte from > > bstr .cbor C509Certificate > > ) > > Grüße, Carsten
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
