Just to be clear:
In our case that means 22 bytes: 80 14 <20 keyid bytes>
Peter
Esko Dijk schreef op 2021-09-08 13:31:
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 <[email protected]> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 10:28
To: [email protected]
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 <[email protected]> On Behalf Of Michael Richardson
Sent: Tuesday, July 27, 2021 02:22
To: [email protected]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher:
what is encoded in the idevid-issuer field?
Toerless Eckert <[email protected]> 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 <[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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
