Dear all, Regarding the ongoing work with draft-ietf-cose-cbor-encoded-cert, we hope to get your opinions on some alternatives regarding non-determinism and compactness.
Our overall stance is that non-determinism in the c509 encoding cannot be fully avoided, if we at all want the draft to evolve and cover more relevant use cases in the future. But we need to both clarify and, as far as possible, reduce the cases where non-determinism could happen. A main area to clarify is the handling of certificate extensions: *Previously we have allowed the registration of certificate extensions in our c509 extension table(^1), without requiring a full accomplishing specification of the cbor encoding of the extension value. Instead allowing the value to be a cbor byte string wrapping of the der-encoded value. This is a clear source of non-determinism, as the expectation is that later additions to the draft will further specify a cbor encoding of the value. The result would be that the receiver of a certificate cannot know beforehand if an extension value is cbor fully encoded or just a der endoced value with byte string wrapping. - We think it would be a useful restriction to only keep extensions with defined cbor encodings of the value, and add this as a requirement for new entries into the table of supported extensions. - For encoded X.509 certificates, any extension would still supported through the more lengthy wrapping of the oid and bstr-wrapped extension value. - We are leaning towards proposing that native c509 must only use cbor encoded extensions. This means that an X.509 extension, which is not covered in the C509 Extensions registry, must be added before being allowed in a native C509 certificate. Does this seem like reasonable restrictions and limitations? Comments and opinions here or directly to our github issue tracker(^2) are most welcome. In addition, there has been an ongoing discussion on adding options for using PENs instead of OID. Since the the cbor encoding of the PENs would need a tag, the savings compared with unwrapped OIDs are only two bytes per PEN. At the same time, support for PEN adds complexity both in the specification and in implementations. To not increase the non-determinism, any OID which can be PEN encoded must be PEN encoded, requiring strict checking. This makes us question whether the savings are worth the drawbacks, and we are interested in hearing any supporting voices from either side of the issue. 1) Ref, C509 Extensions registry: https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-09#name-c509-extensions-registry 2) The main github issue regarding the non-determinism issue https://github.com/cose-wg/CBOR-certificates/issues/197 Best Regards Joel Höglund <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
