Forgot to mention: this thread is based on an open Github issue - https://github.com/anima-wg/constrained-voucher/issues/281 This checks whether cBRSKI can be extended to new cert formats if those become popular. That seems ok, using either option 1 or 2.
> So either way we need to do something now in RFC8366-bis to avoid rolling > that module again later on. With option 2, we can adapt the RFC8366-bis YANG descriptions now, to prepare for new/other cert and key types in the future. With option 1, we can just do nothing now but it would require an update of RFC8366-bis again for each new cert/key type that gets added. So option 2 is some work (now). Certain YANG field descriptions need to be generalized to allow the (future) new key and cert types. > Are you interested in it? > Are you writing code? For now and the coming year, I don't have any plans to use C509 certs or write code for it! If no-one has such plans, we can also decide to go for option 1. > I was hoping (my head in the sand) you wouldn't bring this up :-) I was digging in that sand too deep and found something :) If we treat support for a new cert format (in the DTLS handshake, and in the Voucher) as simply a "new Voucher format" , we don't have to do anything special for this case. Nothing on top of the things already defined now in draft-eckert-brski-discovery. The "new Voucher format" could even have its own media type to distinguish its use of different cert/key encoding. Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: Thursday, December 14, 2023 14:38 To: Esko Dijk <[email protected]>; [email protected] Subject: Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of certificates? Esko Dijk <[email protected]> wrote: > How would the voucher / voucher-request best support such new > certificate formats/types? Two main approaches are possible: Yeah. So either way we need to do something now in RFC8366-bis to avoid rolling that module again later on. > 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 :-) Are you interested in it? Are you writing code? > 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. I was hoping (my head in the sand) you wouldn't bring this up :-) -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
