Hi Michael, Michael Richardson wrote:
>I hope that the compression of DNs will be distinguished such that there is >only one way to do it, and one can compare the compressed forms rather than >having to expand it to be sure. >I don't feel confident that this will be the case because I think that there >will always be an "out" where raw DER bits can be included for things that >the compressor doesn't know how to deal with. So a stupid compressor might >produce a bigger result than a smarter compressor. A long as DER is Distinguished (which it should be) and the CBOR encoding is one-to-one (which it should be) comparing the CBOR encoded DNs will not be a problem. It is hard to comment unless you give more details on why you believe the CBOR encoding would not be one-to-one. As long as certificates really are DER, I think everything will work. If some certs are BER in disguise, we will get problem. >I also wonder about this work in the context of Packed CBOR. >Should we restart our thinking assuming that we are really just building a >static directory for Packed CBOR? I suspect that this bespoke compression >will do better for bytes-on-the wire, but what is the code size impact, >assuming that Packed CBOR code was already available? I do not see how Packet CBOR would replace anything in this context. What is mainly needed here is a DER -> CBOR one-to-one function. CBOR packing is CBOR -> CBOR and it is not one-to-one (it is not a function). Packed CBOR seems to work best on very structured data. Packed CBOR with or without a static dictionary could be used to pack a c5chain of CBOR certificates. I guess you could also theoretically combine a different (not yet specified) DER -> CBOR one-to-one function with a (not yet specified) deterministic one-to-one CBOR packing, and a (not yet specified) dictionary, but I think the "compression" would be limited. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
