Here a question that came up, due to work in COSE WG to define a CBOR-encoded version of the X509 certificate: called "C509 certificate", see draft-ietf-cose-cbor-encoded-cert-07.
Possibly this new C509 certificate format, or other types may become desirable for BRSKI Pledges to use. In particular for constrained BRSKI (cBRSKI), where C509 can reduce the size of messages and/or codebase on the Pledge. How would the voucher / voucher-request best support such new certificate formats/types? Two main approaches are possible: 1. Define new fields for the new certificate format in the YANG definition. So all of the fields that currently hold X509 format are "cloned" to fields for the new format: e.g. pinned-domain-cert, proximity-registrar-cert, pinned-domain-pubk, etc. 2. Re-use the existing fields for the new certificate format. Add a single new field "cert-type" in YANG that has an integer denoting "certificate type". The int value could be taken from existing IANA registry (link<https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3>) So with option (2) the existing fields just hold binary data of some format, by default it's X509/ASN.1 DER. If the "cert-type" field is present it identifies the format of binary data e.g. X509, C509, etc. If we do nothing now, we will default to option 1. TBH I'm not even sure if option 2 is feasible with current YANG definitions and all the legacy around it. But I still wanted to raise this question, just in case anyone's interested :-) PS Also for discovery operations, discovering a Registrar that supports a particular (deviating) certificate type X may then be needed. This could be viewed as just a different type of Voucher that needs to be supported. Esko IoTconsultancy.nl | Email/Teams: esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl> | +31 6 2385 8339
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
