FYI I just added an interpretation #3 to the Github issue which seems to be the right one! Per RFC 5280, any X.509 certificate extension is encoded in an OCTET STRING named "extnValue" as part of the "Extension" ASN.1 item.
So this seems what was meant with "Authority Key Identifier OCTET STRING" in RFC 8366 -> "Authority Key Identifier extension OCTET STRING (i.e. the extnValue)" Regards Esko -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Esko Dijk Sent: Wednesday, September 8, 2021 10:28 To: anima@ietf.org Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field? 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 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
