> On 21. Jan 2026, at 09:53, Ken Takayama <[email protected]> wrote: > > 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?
Extensions encoded as single int consists of one non-critical extension keyUsage, as described in Section 3.1.10: "If the CBOR array contains exactly two ints and the absolute value of the first int is 2 (corresponding to keyUsage, see Section 3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-15#ext-encoding>), the CBOR array is omitted and the extensions is encoded as a single CBOR int with the absolute value of the second int and the sign of the first int." > 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? Not correct. The original text in ID is: "A C509 certificate for a public Diffie-Hellman key would instead have key usage keyAgreement encoded according to Section 3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-15#ext-encoding> (in this case of single extension encoded as integer 16 instead of 1 for digital signature) but otherwise identical in format“ Where "as integer 16 instead of 1 for digital signature“ shall be interpreted as "as integer 16 for key agreement instead of 1 for digital signature“ > 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.) > See above > > 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]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
