Michael Richardson wrote: >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 agree. But you might want to store validity and some extensions as well. Based on your comments I made a commit that moves the two SHA-1 algorithms to -255 and -254. I agree if it is good to indicate that they should not be used in any new certificates (root or not). We can discuss more details of the IANA registrations at some interim meeting. Cheers, John -----Original Message----- From: Michael Richardson <[email protected]> Date: Thursday, 26 November 2020 at 18:21 To: John Mattsson <[email protected]>, cose <[email protected]> Subject: Re: [COSE] CBOR Certificates Open Issues 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
