To the authors of the C509 Certificates draft, My name is Ken Takayama. I understand that the document has already been submitted to the IESG, but I recently reviewed Section 3.1.10 in detail and found one question and one concern that I would like to raise.
[Current draft] > 3.1. Message Fields > > Extensions = [ * Extension ] / int > > Extension = (( extensionID: int, extensionValue: Defined ) // > ( extensionID: ~oid, ? critical: true, > extensionValue: bytes )) > > > 3.1.10. extensions > The 'extensions' field is encoded either as a CBOR array or as a CBOR > int. An omitted 'extensions' field is encoded as an empty CBOR array. Question: When Extensions is encoded as a single int, what does this represent? Appendix A.1.1. states that the value 1 represents a single extension: non-critical keyUsage digitalSignature. Appendix A.1.3. indicates that the value 16 represents a public Diffie-Hellman key. Is this interpretation correct? And where can I find the specification or definition of this special integer encoding? It might be helpful if Section 3.1.10 could clarify that, when a single Extension is encoded as an int, the value corresponds to the definitions provided in the relevant appendices. (It seems that Appendix A.1.1 and A.1.3 alone may not fully cover all such cases.) Concern: Interoperability of `Defined` I am worried about the CDDL definition `extensioValue: Defined`, and for two reasons I believe that the extensionValue should also be bytes when the extensionID is an int. 1. There will likely be a need to safely skip over extensions that cannot be interpreted. If extensionValue is `any`, the CBOR parser may encounter a type it cannot decode, which could cause processing of the entire certificate to fail. 2. As stated in Section 4 of RFC 8742, CDDL currently has no definition for `cbor-seq`, and it appears that `cbor-seq` is not included in `any`. However, if CDDL were extended in the future to include `cbor-seq` within `any`, then something like: ```diag / extension: / [ 100, 2, 3 ] ``` could result in `2, 3` being interpreted as a `cbor-seq`, and the structure might be considered valid under such CDDL. Would this not create an unintended acceptance of such encodings? I think the additional size for each extension is justified by the improved interoperability. Best regards, Ken _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
