Hi Laurence, Thank you for your observations and comments!
I can't answer for what operations Stefan are using in his implementation, but to continue discussing the possible solutions I'm interested in clarifying the expectations on an off-the-shelf CBOR implementation: When you talk about using off-the-shelf CBOR implementations, do you expect to not have to do any other byte-level operations at all? Such as knowing/updating an offset to step into a sequence, or byte level array copying. I fully support that we should provide an encoding solution that does not require hacking the CBOR implementation itself, so I think the discussion should be which extra decoding/encoding operations we think are acceptable on top of an existing CBOR implementation. (For me, with the minimal on the wire size perspective, to change the CBOR cert definition to completely align with COSE seems like a less attractive option, but this is of course open for discussion, if the advantages are deemed to outweigh the drawbacks.) Best Regards Joel Höglund On Mon, 14 Dec 2020 at 20:09, Laurence Lundblade <[email protected]> wrote: > Hi Stefan, > > First on the implementation — my understanding is that you’d have to hash > from the byte offset of the first byte of the CBOR encoded head of > cborCertificateType to the last byte of the Extensions to correctly > implement this. Since the cborCertificateType is the first item in the > sequence, its offset is zero, so that’s easy. > > I’m not sure how you’d use cbor_value_calculate_string_length since many > of the items in the TBSCertificate are not strings. Maybe you calculate the > length of the issuerSignatureValue and go back from the end? That > wouldn’t account for CBOR encoded head of issuerSignatureValue though. > > So, I don’t understand how this works with tinyCBOR or that it is even > correct. > > It would be good to see an implementation in Python or Go or such to see > if it's possible with those type of CBOR decoders. > > > Second on the design — I still believe this design is counter > to conventions used in CBOR for signing/hashing data. I think the folks > that designed COSE thought this issue through. > > > (My first design of of EAT did the hashing the way it is being done here. > This was before COSE was publishes as an RFC. The folks using an > off-the-shelf Python CBOR decoder had to hack that decoder to get the > verification to work. Then EAT switched to COSE and I came to understand > the reasons COSE works as it does.) > > LL > > > > On Dec 14, 2020, at 5:50 AM, Hristozov, Stefan < > [email protected]> wrote: > > 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]> 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]" <[email protected]> > > Date: Wednesday, 2 December 2020 at 08:56 > > To: Göran Selander <[email protected]>, Göran Selander < > [email protected]>, Martin Furuhed < > [email protected]>, Shahid Raza <[email protected]>, John > Mattsson <[email protected]>, Joel Hoglund <[email protected]>, > John Mattsson <[email protected]>, Joel Höglund < > [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] > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > [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] > https://www.aisec.fraunhofer.de/ > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
