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
