Hi, Thank again Henk, Ilari, Carsten, Jim, Russ, for the very good comments during the summer. I think I have now addressed all of them in the GitHub version, and also implemented a large part of the draft. Based on the discussion and suggestions, the plan is to focus on encoding and let other decide what to put in the certificates. We believe that the encoding can be made as general as the group want, while still enable simple and very efficient encoding of the most constrained IoT certificates. The specification is now able to encode most HTTPS certificates on the web, while the encoding of the example RFC 7925 certificate is still 138 bytes (56% saving).
https://ericssonresearch.github.io/CBOR-certificates/draft-mattsson-cose-cbor-cert-compress.html Additional changes planned for -03: - Update title based on comment from Jim - Updated abstract and intro so it is up to date with the document: "This document specifies a CBOR encoding of PKIX profiled 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 producing very small sizes for certificates compatible with RFC 7925. The CBOR encoding can be used to compress DER encoded X.509 certificated to encode natively signed certificated." - Added text that the string types teletexString, universalString, and bmpString are not supported. - Allowed raw relative OIDs for algorithms and extensions. - Added more detail on how ECDSA signatureValue is encoded as two integers padded to length L = ceil( log2(n) / 8 ), where n is the order of the curve. For secp256r1, secp384r1, and secp521r1, L is 32, 48, and 66 respectively. - Updated CDDL to follow RFC 8742 recommendations - Fixed an empty subject can be encoded. - Completely rewrote extension encoding as the old description was underspecified, had several problems, and several limitations. - Added text highlighting that also natively signed CBOR certificates can reuse much of the CA machinery, as only the last signing step need to be updated. - Added IANA registries for extensions, EKU, and subjectaltname - Added registration procedures for the IANA registries. - Added c5bag and c5t as well. - Formatted the DER and CBOR encoding with space to make them easier to read. - Specified how EUI-64 is compressed to 6 or 8 bytes (the practice of creating EUI-64 seems to have been deprecated, needs to be discussed) - The specification can now encode most HTTPS certificates on the web (even if most extension values are just DER encoded byte strings). The encoding of the tools.ietf.org certificate was added as an example. The compression is (270 bytes or 16%). - Added acknowledgements Cheers, John -----Original Message----- From: John Mattsson <[email protected]> Date: Wednesday, 4 November 2020 at 23:40 To: "[email protected]" <[email protected]> Subject: FW: New Version Notification for draft-mattsson-cose-cbor-cert-compress-02.txt Hi, Thanks for all the reviews and comment during summer and autumn! The comments have indicated that the CBOR certificates should support a much larger subset of RFC 5280, that the draft should not be so much of a profile, but also that any updates should not expand the certificate sizes for the most constrained use cases. We think this is possible to achieve. We have submitted draft-mattsson-cose-cbor-cert-compress-02. Changes are: - Changed terminology to "natively signed" - Completely changes the encoding of issuer and subject. The new encoding supports encoding of sequences of sets of attribute types and values. The encoding should be able to handle any attribute type encoded as utf8string and printableString. Is that enough or do we need to support also legacy teletexString, universalString, bmpString, Ia5string? Is any attributeType missing or are the MUST and SHOULD support in RFC 5280 enough? - Moved signatureAlgorithm so it comes before signatureValue. Made the algorithms explicit and split them into two items. - Extension text moved to separate paragraph. We made some small changes to the extension coding, but based on the discussion and suggestions to support much more, we believe the encoding might have to change quite much. We plan to make further updates after the group has agreed on what to support. - Split CDDL into certificate and tbsCertificate similar to RFC 5280 to not have to duplicate CDDL. - New section of compliance requirements. We did not have to address all the comments in -02 and have already starting to work on -03, which we plan to submit during IETF week. If you want to review, please review the GitHub version https://ericssonresearch.github.io/CBOR-certificates/draft-mattsson-cose-cbor-cert-compress.html Changes in -03 so far: - Added GeneralizedTime as suggested by Jim. We also addresses an issue in that the old encoding could not encode leap seconds (which X.509 can). To enable this we swiched from uint to bytes, where a byte string of length 4 represent a UTCTime and a byte string of length 5 represent a GeneralizedTime. - Changed from TLS compression algorithms to TLS certificate Type as suggested by Ilari. This also enables CBOR certificates to be used with a general compression algorithm in TLS, which is not helping for very contrained certificates but probably reduce the size quite much for non-IoT cbor certificates with a lot of character strings. - We looked into which algorithms can be supported without parameters. Proposal is to not support algorithms with parameters except namedcurves. Looking at RSA-PSS with SHAKE, X25519, Ed25519, and hash-bases algorithms it seems like all new algorithms will be specified without parameters. Do people feel that any algorithms with paramaters should be supported? Algorithms that use parameters are e.g. RSA-PSS keys and signatures with SHA2, ECC keys without named curves. - More strict text on several parts regarding encoding. Cheers, John -----Original Message----- From: "[email protected]" <[email protected]> Date: Monday, 2 November 2020 at 12:34 To: Göran Selander <[email protected]>, Joel Hoglund <[email protected]>, Martin Furuhed <[email protected]>, John Mattsson <[email protected]>, Shahid Raza <[email protected]>, Göran Selander <[email protected]>, John Mattsson <[email protected]>, Joel Höglund <[email protected]> Subject: New Version Notification for draft-mattsson-cose-cbor-cert-compress-02.txt A new version of I-D, draft-mattsson-cose-cbor-cert-compress-02.txt has been successfully submitted by =?utf-8?q?G=C3=B6ran_Selander?= and posted to the IETF repository. Name: draft-mattsson-cose-cbor-cert-compress Revision: 02 Title: CBOR Profile of X.509 Certificates Document date: 2020-11-02 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/archive/id/draft-mattsson-cose-cbor-cert-compress-02.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-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-mattsson-cose-cbor-cert-compress-02 Abstract: This document specifies a CBOR encoding/compression of RFC 7925 profiled certificates. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document also specifies COSE headers for CBOR encoded certificates as well as the use of the CBOR certificate compression algorithm with TLS Certificate Compression in TLS 1.3 and DTLS 1.3. 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
