(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]
