Hi Lijun, The change from -19 to -20 didn’t change C509Certificate. Certificates are an array in both.
It looks like -19 attempted to use ~ (unwrap) to remove the array grouping to yield a sequence. But ~ only works on tag numbers, not arrays. So -19 had some errors/inconsistencies in it. Seems like it would be good to update the test vectors and implementations before final publication of -20 as in RFC. Kind of a large misunderstanding for a document with so much development time. LL > On Jul 21, 2026, at 12:45 PM, Lijun Liao <[email protected]> > wrote: > > Hi Laurence, > > draft-ietf-cose-c509-test-vectors-01 (the current version) aligns with the > draft-ietf-cose-cbor-encoded-cert-19. > > In -19, the content of a certificate file is not C509Certificate (CBOR > array), but the unwrapped C509Certificate (CBOR sequence). That is why the > test vectors there do not start with 0x8B. > > We are planning to update the test vectors to align the latest > draft-ietf-cose-cbor-encoded-cert-20. > > Lijun > > From: Laurence Lundblade <[email protected]> > Date: Tuesday, 21. July 2026 at 21:07 > To: cose <[email protected]> > Subject: [COSE] Tweaks to draft-ietf-cose-c509-test-vectors? > > CAUTION! External Email. Do not click links or open attachments unless you > recognize the sender and know the content is safe. > > (sending a 2nd time to the intended COSE list rather than the CBOR list) > > Hi, > > If I understand correctly, a C509 Certificate when it sits in a file, or in a > protocol message or such is always grouped in an array and the first encoded > byte is always 0x8B (the CBOR encoding for an array of 11 elements). There > are no cases where that isn’t true, right? You can always do a sniff test on > the first two bytes and reject anything where the first byte is not 0x8B and > the second byte is not 0x02 or 0x03. > > draft-ietf-cose-c509-test-vectors has over 20 examples called "C509 Type X > Certificate”, that aren’t like this. They leave off the array, the 0x8B. > Seems like an inconsistency. > > Seems like draft-ietf-cose-c509-test-vectors should be kept around as a great > set of examples/test vectors. > > Seems like it would be best to add the 0x8B into all these examples so they > are real-world examples. Alternatively, there could be a big note saying they > are only partial examples. Or title the sections “TBSCertificate of Type X” > instead of "C509 Type X Certificate”. > > > I’m bringing this up because an important part of a C509 implementation is > the extraction of the undecoded TBSCertificate CBOR. Those are the bytes that > go into the sig/hash for native signed C509. The means for this extraction > varies by CBOR library and some might not do it at all. My CBOR library, > QCBOR, couldn’t do it at all until I added the Tell() feature in 2024. > > LL > > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > <http://www.nio.io/> > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > You may NOT use, disclose, copy or disseminate this information. If you have > received this email in error, please notify the sender and destroy all copies > of the original message and all attachments. Please note that any views or > opinions presented in this email are solely those of the author and do not > necessarily represent those of the company. Finally, the recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > _______________________________________________ > 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]
