Hi, Thank the great discussion. I hope we can discuss some more during today’s interim.
Stefan Hristozov wrote: > which I was not cable to do because the public key of the CA is not given in > the test vector. In version -05 of the draft, the public and private key of the CA are included: All of the the above example certificate were signed and can be verified with the following key pair where the private key is encoded as in COSE [RFC8152<https://tools.ietf.org/html/rfc8152>]. issuerPublicKeyAlgorithm : 1 (id-ecPublicKey + secp256r1) issuerPublicKey : h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E' issuerPrivateKey : h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2' (Version -06 of the draft will also include the private key of the subject in the example certificate. This makes it possible to use the example certificate in e.g., EDHOC test vectors) Göran Selander wrote: I’m aware of two implementation activities: by John (type 1) and by Stefan (type 0). I have so far only implemented DER -> CBOR (type 1). I started in C++17 but have now moved to Rust. I wrote my own DER decoder and CBOR encoder. The reason I wrote everything myself was to make sure I understand all the nitty gritty details of DER and CBOR. I plan to release the source code when I have cleaned it up a bit. John From: "Hristozov, Stefan" <[email protected]> Date: Tuesday, 15 December 2020 at 16:34 To: "[email protected]" <[email protected]> Cc: John Mattsson <[email protected]>, Göran Selander <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [COSE] bstr wrapping for native signed (was Re: New Version Notification for draft-mattsson-cose-cbor-cert-compress-05.txt) Hi Laurence, i don't have an implementation in higher languages such as Python or Go, so i decided to code it today in Rust ( just for fun). Find my implementation attached. I tested this implementation with test vector A.1.1. I have a function called decode_native which returns a struct containing the decoded certificate fields "decoded_data", the encoded certificate fields "signed_data" and the signature "signature". To verify the certificate we need to provide the signed_data and signature to a verification function, which I was not cable to do because the public key of the CA is not given in the test vector. Decoding test vector A.1.1 my implementation generates the fowling result: ----------------------------------------------------- cbor_cert_type is: 1 cert_serial_number is: [01, f5, 0d] issuer is: [82, 70, 67, 32, 116, 101, 115, 116, 32, 67, 65] validity_not_before is: 1577836800 validity_not_after is: 1612224000 subject is: [01, 23, 45, 67, 89, ab] subject_pk_alg is: 1 subject_pk is: [02, b1, 21, 6a, b9, 6e, 5b, 3b, 33, 40, f5, bd, f0, 2e, 69, 3f, 16, 21, 3a, 04, 52, 5e, d4, 44, 50, b1, 01, 9c, 2d, fd, 38, 38, ab] extensions is: 1 issuer_sgn_alg is: 6 signed_data is: [01, 43, 01, f5, 0d, 6b, 52, 46, 43, 20, 74, 65, 73, 74, 20, 43, 41, 1a, 5e, 0b, e1, 00, 1a, 60, 18, 96, 00, 46, 01, 23, 45, 67, 89, ab, 01, 58, 21, 02, b1, 21, 6a, b9, 6e, 5b, 3b, 33, 40, f5, bd, f0, 2e, 69, 3f, 16, 21, 3a, 04, 52, 5e, d4, 44, 50, b1, 01, 9c, 2d, fd, 38, 38, ab, 01, 06] signature is: [44, 5d, 79, 8c, 90, e7, f5, 00, dc, 74, 7a, 65, 4c, ec, 6c, fa, 6f, 03, 72, 76, e1, 4e, 52, ed, 07, fc, 16, 29, 4c, 84, 66, 0d, 5a, 33, 98, 5d, fb, d4, bf, dd, 6d, 4a, cf, 38, 04, c3, d4, 6e, bf, 3b, 7f, a6, 26, 40, 67, 4f, c0, 35, 4f, a0, 56, db, ae, a6] ----------------------------------------------------- Very similar code can be achieved also with tinyCBOR in C. Many values are not strings you are right so cbor_value_calculate_string_length cannot be used but integers therefore to get their length is not difficult. I hope this code helps. What exactly do you mean by hacking the decoder? Do you mean to track the offset? What are the alternatives? Best regards, Stefan PS: I know the code contains a lot of copy+paste and needs to be refactored. On Mon, 2020-12-14 at 11:09 -0800, Laurence Lundblade 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]<mailto:[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<https://protect2.fireeye.com/v1/url?k=5c0bb111-03908852-5c0bf18a-861fcb972bfc-06cd73c092163b93&q=1&e=5e295a93-a44c-4f30-9642-65f681a6b5ec&u=https%3A%2F%2Fgithub.com%2Fintel%2Ftinycbor> [2]: https://intel.github.io/tinycbor/current/a00047.html#gad5b2dd803244946b15603e09ce147044<https://protect2.fireeye.com/v1/url?k=73373c09-2cac054a-73377c92-861fcb972bfc-798ce0d2767b9e63&q=1&e=5e295a93-a44c-4f30-9642-65f681a6b5ec&u=https%3A%2F%2Fintel.github.io%2Ftinycbor%2Fcurrent%2Fa00047.html%23gad5b2dd803244946b15603e09ce147044> 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]<mailto:[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<http://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]<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
