emanjon
commented
3 years ago I think we should define COSE_C509 as something like
COSE_C509 = [ comp : int, C509Certificate / [ 2* C509Certificate ] / bytes]
where comp = 0 is no compression and other values of comp are use for a compressed chain conveyed in a bstr. This provides significant further compression when applied to example HTTPS certificate chains. The numbers below are from TLS but would be approximate for COSE_C509 as well.
+-------------------+------+---------------+
| | C509 | C509 + Brotli |
+-------------------+------+---------------+
| ECDSA HTTPS Chain | 1409 | 1058 |
+-------------------+------+---------------+
| RSA HTTPS Chain | 3957 | 2841 |
+-------------------+------+---------------+CBOR packed could be used in a similar way (unclear how that performs)
highlunder
The TLS size examples in the -01 draft shows that even after C509 encoding, Brotli can still compress a cetificate chain quite much.
Test on RPKI certs should that Brotli can compress individual extensions or certs quite much, even after CBOR encoding.
I think we should discuss if Brotli (or some other general compression mechanism should be used in COSE. Likely after the signature has been calculated, i.e. not in individual extensions.
There has also been discussion on using CBOR packed, but there has to my knowledge not been any tests being done. https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed-02