Hi Laurence, I am using the C library tinycbor [1] for my native CBOR certificate decoder. During parsing the certificate I am calculating also an offset from its beginning after each parsed element. Tinycbor provides a function for getting the length of the byte or text string cbor_value_calculate_string_length [2], which is helpful for that.
Does this answer your question? Best regards, Stefan [1]: https://github.com/intel/tinycbor [2]: https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044 On Mon, 2020-12-14 at 13:18 +0000, Göran Selander wrote: Hi Laurence, I’m aware of two implementation activities: by John (type 1) and by Stefan (type 0). Göran On 2020-12-07, 23:02, "COSE" <[email protected]> wrote: I don’t think it works very well at all to directly sign encoded CBOR. It should be wrapped in a byte string. In particular issuerSignatureValue should probably be the signature over a byte string that contains an encoded TBSCertificate. This is what COSE does. The main reason for this is to allow implementation with off-the-shelf CBOR encoders and decoders. From some that I’ve looked at and one I’ve written myself, CBOR decoders don’t allow access a sub-part of the encoded CBOR so it can be input into the hash. There would be no way to get just the encoded bytes of the TBSCertificate out of the CBOR decoder unless you went in and hacked its source code in a special way. Has anyone implemented verification of Natively Signed CBOR Certificates? What CBOR decoder was used? Maybe I’m wrong about this? I realize byte string wrapping TBSCertificate might cause upheaval in the overall design because cborCertificateType would be inside the byte string wrapping. Another approach might be to just use COSE for Natively Signed CBOR Certificates. The COSE payload would be a TBSCertificate. COSE would take care of the byte string wrapping issues. This would increase the on-the-wire size of the certificate by about 10 bytes, but might decrease code size of the implementation by re use of a COSE implementation. LL > On Dec 2, 2020, at 12:49 AM, John Mattsson > <[email protected]<mailto:[email protected]>> > wrote: > > Thanks again for all the good comment and discussions on the list! > > We have submitted -05. Changes are: > > - Added reference to IEEE 802.1AR DevID and made optimization for IEEE > 802.1AR DevID. > - Rephrased "compress" in the whole document. We will change the file name > later. > - Made it more clear that X.509 version in included in the CBOR certificate > type. > - Omitted 'signature' instead of 'singatureAlgorithm'. Now the algorithm > comes just before the signature value. > - Added support of emailAddress / IA5String in issuer and subject. This was > easy. > - changed so utf8Strings have a positive sign. > - Change time to unwrapped CBOR epoch time (~time). This saves 1 byte for > time > 2050 > - Added that the value "99991231235959Z" (no expiration date) is encoded as > CBOR null. This is quite commonly used in IoT certificates. This saves 4 > bytes when used. > - Use CDDL for CBOR OID as defined in draft-ietf-cbor-tags-oid > - Added CBOR encoding for uthorityKeyIdentifier and subjectKeyIdentifier > which are heavily used by IEEE 802.1AR DevID (at least one of them are > mandated depending on type of cert). > - Added optimization for the hardwareModuleName type of otherName, which is > mandatory to use in IEEE 802.1AR DevID > - Added CBOR encoding for cRLDistributionPoints and authorityInfoAccess, > which are both used in basically all HTTPS certificates on the web. > - Added support for registeredID. This was trivial and registeredID is used > e.g. by the GSMA eUICC PKI Certificate Policy (SGP 14). > - Added considerations for expert reviewers. > - Moved SHA-1 signature algorithms to negative 2 byte encodings: -256 and -255 > - Added a public private ECDSA key pair turning the example certificates into > test vectors. An implementation can now create and verify the example RFC > 7925 certificates. > > Cheers, > John > > -----Original Message----- > From: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Date: Wednesday, 2 December 2020 at 08:56 > To: Göran Selander > <[email protected]<mailto:[email protected]>>, Göran > Selander <[email protected]<mailto:[email protected]>>, > Martin Furuhed > <[email protected]<mailto:[email protected]>>, Shahid > Raza <[email protected]<mailto:[email protected]>>, John Mattsson > <[email protected]<mailto:[email protected]>>, Joel Hoglund > <[email protected]<mailto:[email protected]>>, John Mattsson > <[email protected]<mailto:[email protected]>>, Joel Höglund > <[email protected]<mailto:[email protected]>> > Subject: New Version Notification for > draft-mattsson-cose-cbor-cert-compress-05.txt > > > A new version of I-D, draft-mattsson-cose-cbor-cert-compress-05.txt > has been successfully submitted by =?utf-8?q?John_Preu=C3=9F_Mattsson?= and > posted to the > IETF repository. > > Name: draft-mattsson-cose-cbor-cert-compress > Revision: 05 > Title: CBOR Encoding of X.509 Certificates (CBOR Certificates) > Document date: 2020-12-01 > Group: Individual Submission > Pages: 29 > URL: > https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-05.txt > Status: > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress > Htmlized: > https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-05 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-05 > > Abstract: > This document specifies a CBOR encoding of X.509 certificates. The > resulting certificates are called CBOR Certificates. The CBOR > encoding supports a large subset of RFC 5280, while at the same time > significantly reduces the size of certificates compatible with RFC > 7925 and IEEE 802.1AR (DevIDs). When used to re-encode DER encoded > X.509 certificates, the CBOR encoding can in many cases reduce the > size of RFC 7925 profiled certificates with over 50%. The CBOR > encoding can also be used encode "natively signed" CBOR certificates, > which does not require re-encoding for the signature to be verified. > The document also specifies COSE headers as well as a TLS certificate > type for CBOR certificates. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > COSE mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose -- Stefan Hristozov Department Hardware Security Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich, Germany Tel. +49 89 32299 86 157 [email protected]<mailto:[email protected]> https://www.aisec.fraunhofer.de/
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
