John Mattsson <[email protected]> wrote: > 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.
Okay, I've re-read the document.
I thought that there were some outs, i.e. if some rarely occuring thing
occured that it could be sent as pieces of DER. No such things occur.
So, I agree, we can compare CBOR encoded DNs.
My point remains that an IoT device storing a root certificate only needs the
public key and *maybe* the DN, if it has more than one such anchor.
>> 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.
I guess you are right.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
