Hi Peter,
No for option #3 it still needs to be wrapped into another OCTET STRING, for
example:
041830168014D5039FC78A4DC0468760191FD71B1534C2D88428
(24 bytes)
Which decodes as:
OCTET STRING (24 byte) 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
SEQUENCE (1 elem)
[0] (20 byte) D5039FC78A4DC0468760191FD71B1534C2D88428
It may be that some APIs of libraries actually remove the ‘OCTET STRING’
wrapping as a convenience to the user, since any extension is wrapped into an
OCTET STRING.
I still have to check that for my implementation.
Esko
From: Peter van der Stok <[email protected]>
Sent: Wednesday, September 8, 2021 15:02
To: Esko Dijk <[email protected]>
Cc: [email protected]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is
encoded in the idevid-issuer field?
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]<mailto:[email protected]>> On Behalf
Of Esko Dijk
Sent: Wednesday, September 8, 2021 10:28
To: [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf
Of Michael Richardson
Sent: Tuesday, July 27, 2021 02:22
To: [email protected]<mailto:[email protected]>
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is
encoded in the idevid-issuer field?
Toerless Eckert <[email protected]<mailto:[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]<mailto:[email protected]>> . o
O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
