do a quick check that future certificate formats can be supported

[EskoDijk]

In particular, new formats like x509-in-CBOR . Procedure should be ready to extend to new cert types?

Have a look again at https://datatracker.ietf.org/doc/html/rfc9360 (check how this RFC could apply further than already currently used)

[EskoDijk]

See also new C509 CBOR-based cert format: https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-07

[EskoDijk]

Checklist what is needed for supporting new certificate formats - using the new C509 format as an example

• Content-Formats to carry new cert formats in EST-coaps - ok: CoAP can be extended to any new content-formats, using Content-Format Option and Accept Option.
• Alternatives to x5bag to carry new cert formats in Voucher or Voucher-request - ok: draft-ietf-cose-cbor-encoded-cert-07 already defines x5bag alternatives (c5b, c5c)
• Alternative to Voucher pinned-domain-cert, pinned-domain-pubk* fields: new fields can be defined in the Voucher, as an extension.
• Alternative to Voucher proximity-registrar-cert, proximity-registrar-pubk* fields: new fields can be defined in the Voucher, as an extension.
• New certificate formats in handshake of DTLS: section 9.13 of draft-ietf-cose-cbor-encoded-cert-07 registers a new certificate type in the following registry: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 . This way the C509 cert can also be used in the handshake.
• Discovery of Registrar that supports particular cert type: there's ongoing work in draft-eckert-brski-discovery to discover Proxy or Registrar that supports particular methods/types. Can support a new 'parameter' such as cert type.

Concluding, there are no showstoppers for supporting new cert types in the future.

Open question: do we want to write an appendix (informative) that explains all these aspects, for future support of new cert types like C509? Current draft is already quite long.