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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
