Thanks all for the useful discussion on this topic! We hit this issue again during interop this week and decided for now to use the option to include in "idevid-issuer" the complete ASN.1 AuthorityKeyIdentifier SEQUENCE, since one implementation was already using that for a while now; and using the same thing helps in the interop work.
Created an issue in Github to mark our final decision at some point: https://github.com/anima-wg/constrained-voucher/issues/161 Best regards Esko -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Michael Richardson Sent: Tuesday, July 27, 2021 02:22 To: anima@ietf.org Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? Toerless Eckert <t...@cs.fau.de> wrote: > Which gets us back to the case you mention, which is one and the same vendor > (shudder) reusing serial numbers. > a) Are we aware of any actual instance of this ? Yes... the bigger the org, the less anyone has any idea what's going on globally. And then add in mergers/acquisitions. > If something like this would be a stupid but possible case, then > i would like us to write somehing short about this into rfc8366bis > so readers can understand why this differentiation by KeyIdentifier > may be useful to have. I agree that we could clarify the use of this field. One thing that I don't like is that it's hard to write/edit/revise the "description" field in the YANG, and more and more, I'd like to just say, "See RFCXXXX section Y.Z" in the description. That might not fly as a process. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
