Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

From: Esko Dijk <[email-masked]>
Date: Wed, 8 Sep 2021 08:28:27 +0000

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-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, July 27, 2021 02:22
To: [email-masked]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Toerless Eckert <[email-masked]> 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-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Esko Dijk <[email-masked]>
Date: Wed, 8 Sep 2021 11:31:12 +0000

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-masked]> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 10:28
To: [email-masked]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Best regards
Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, July 27, 2021 02:22
To: [email-masked]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 08 Sep 2021 15:02:08 +0200

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:

> Per RFC 5280, any X.509 certificate extension is encoded in an OCTET 
> STRING named "extnValue" as part of the "Extension" ASN.1 item.
> 
> Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: 
> what is encoded in the idevid-issuer field?
> 
> 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
> 
> Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: 
> what is encoded in the idevid-issuer field?
>

---

From: Esko Dijk <[email-masked]>
Date: Wed, 8 Sep 2021 13:16:05 +0000

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-masked]>
Sent: Wednesday, September 8, 2021 15:02
To: Esko Dijk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Just to be clear:

Peter

Regards
Esko

-----Original Message-----
From: Anima <[email-masked]<mailto:[email-masked]>> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 10:28
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Best regards
Esko

-----Original Message-----
From: Anima <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Tuesday, July 27, 2021 02:22
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Esko Dijk <[email-masked]>
Date: Wed, 8 Sep 2021 14:01:32 +0000

> 041830168014D5039FC78A4DC0468760191FD71B1534C2D88428

I meant here 26 bytes, sorry!
So 2 bytes 04 18 are used to encode ‘OCTET STRING’, 2 bytes 30 16 for ‘SEQUENCE’, 2 bytes 80 14 for the ‘[0]’ and the rest is the actual KeyIdentifier (20 bytes).

Esko

From: Anima <[email-masked]> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 15:16
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Hi Peter,

Which decodes as:

Esko

From: Peter van der Stok <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 8, 2021 15:02
To: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Just to be clear:

Peter

Regards
Esko

-----Original Message-----
From: Anima <[email-masked]<mailto:[email-masked]>> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 10:28
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Max/*: Re: RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Best regards
Esko

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 13:04:56 -0400

Esko Dijk <[email-masked]> wrote:
    > 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)"

Worthwhile clarifying in constrained-voucher.
Should it also be an errata against RFC8366?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 13:12:05 -0400

RFC8366 specifies a idevid-issuer to identify the CA that issued the IDevID.
It says:
  https://www.rfc-editor.org/rfc/rfc8366.html#section-5.3

leaf idevid-issuer {
        type binary;
        description
          "The Authority Key Identifier OCTET STRING (as defined in
           Section 4.2.1.1 of RFC 5280) from the pledge's IDevID
           certificate.  Optional since some serial-numbers are
           already unique within the scope of a MASA.
           Inclusion of the statistically unique key identifier
           ensures statistically unique identification of the hardware.
           When processing a voucher, a pledge MUST ensure that its
           IDevID Authority Key Identifier matches this value.  If no
           match occurs, then the pledge MUST NOT process this voucher.

           When issuing a voucher, the MASA MUST ensure that this field
           is populated for serial-numbers that are not otherwise unique
           within the scope of the MASA.";
      }

We have some discussion about what exactly this means.
https://github.com/anima-wg/constrained-voucher/issues/161 captures this as
three possibilities:

1) only the KeyIdentifier OCTET STRING
2) the complete AuthorityKeyIdentifier ASN.1 SEQUENCE structure
3) the complete Authority Key Identifier extension OCTET STRING value 'extnValue' per Section 4.1 of RFC 5280

Esko suggests that (3) is the correct thing, detailed as:

OCTET STRING (26 byte) 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
  SEQUENCE (1 elem)
    [0] (20 byte) D5039FC78A4DC0468760191FD71B1534C2D88428

> So 2 bytes 04 18 are used to encode ‘OCTET STRING’, 2 bytes 30 16 for
> ‘SEQUENCE’, 2 bytes 80 14 for the ‘[0]’ and the rest is the actual
> KeyIdentifier (20 bytes).

We think this consistent with other users of Authority Key Identifier.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [