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

From: Esko Dijk <[email-masked]>
Date: Fri, 23 Jul 2021 15:30:39 +0000

Hello all,

From the hackathon/interop we hit an interesting difference in spec-reading viewpoints that I would like to bring to the list.

*** Question and context
The question is what is included in the ‘idevid-issuer’ field? RFC 8366 states that it is binary and:

           The Authority Key Identifier OCTET STRING (as defined in
           https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1) from the pledge's IDevID
           certificate.  

We can look at the 4.2.1.1 RFC 5280 definition:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

*** Interpretation #1
take the OCTET STRING part of the Authority Key Identifier, i.e. the " Authority Key Identifier OCTET STRING "  which is the last line == KeyIdentifier.
So only the ASN.1 bytes encoding 'KeyIdentifier' are included there because this is the OCTET STRING part of it as indicated. That is why OCTET STRING is written in capitals in RFC 8366.

Note that the keyIdentifier MUST be there for non-self-signed certs per RFC 5280:
“The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction”

So for this reason one can rely on purely the keyIdentifier part of the AKI; and one could think that RFC 8366 was stating this.

*** Interpretation #2
The OCTET STRING is the entire structure AuthorityKeyIdentifier , encoded in ASN.1 format (=JSON Octet String encoding in a JSON Voucher, or in CBOR voucher a ‘byte string’ CBOR type).
Even though the AuthorityKeyIdentifier  SEQUENCE is not labeled as “OCTET STRING” in capitals in RFC 5280, this is what is intended because it can be encoded as an octet string in the voucher and is also encoded as octet string (coding for ASN.1 SEQUENCE) in ASN.1.

Now I wonder which is right/intended?
And furthermore for constrained use cases would it be ok to take it out as the text in RFC 8366 suggests is okay? E.g. if serialNumber is unique across all Pledges made by Vendor X.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]    |   +31 6 2385 8339

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Jul 2021 19:34:24 +0200

Unfortunately, i have to pile on instead of just answering:

I can not remember that we ever constructed a case where his
field was necessary when we wrote rfc8366. At least, we did
not document it e.g. in the examples. Such an example, explanation
would now be very helpfull in answering your question. Or at leas
for me to wrap my head around it.

I for once can not come up with a case where this field would
be anything else than what is in the CMS signerInfo, aka: this
field is redundant. And creating correct interop for
a redundant field is some somewhat non-motivational.

So, if anyone can lay out an example where this field is
actually required, i would be a lot more incentivised
to think about an answer. But primarily i'd like tha
type of example to be added to rfc8366bis.

Cheers
    Toerless

P.S.: I think it is [1], primarily because it would be
strange to map a CMS structure just into a single CMS
octet string field instead of mapping it 1:1.

>            https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1) from the pledge's IDevID

Sounds like at least the start for an errata against RFC8366.
Not sure if we can start filing an errata when we agree that
the spec is ambiguous *sigh*.

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

-- 
---
[email-masked]

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 23 Jul 2021 22:00:40 +0000

Inline,

> On Jul 23, 2021, at 11:34 AM, Toerless Eckert <[email-masked]> wrote:
> 
> 
> actually required,

Pulling from the YANG module description in s5.3 of RFC8366

This leaf is "Optional since some serial-numbers are already unique within the scope of a MASA” because, within the scope of a manufacturer authorized signing authority that is truly provided by the manufacturer one could reasonably expect the serial number to be unique. I mean, what kind of manufacturer would sell multiple devices with the same serial number? They’d just be shooting themselves in the foot. 

So the use case here is for a MASA servicing devices that might plausibly have the same serial number; where "the statistically unique key identifier ensures statistically unique identification of the hardware”. This could obviously occur if a manufacture was, shudder, re-using serial numbers. It is more likely to occur when the MASA is a service authorized by the manufacturer that also handles multiple manufacturers. 

For example in: https://datatracker.ietf.org/doc/html/draft-friel-anima-brski-cloud-04.html#section-1.2

"While a Cloud Registrar will typically handle all the devices of a
   particular product line from a particular manufacturer there are no
   restrictions on how the Cloud Registrar is horizontally (many sites)
   or vertically (more equipment at one site) scaled.  It is also
   entirely possible that all devices sold by through a particular VAR
   might be preloaded with a configuration that changes the Cloud
   Registrar URL to point to a VAR.

Now to the original question, is this the entire “AuthorityKeyIdentifier” SEQUENCE or the KeyIdentifier OCTET STRING?

My intuition is Interpretation #1, just the KeyIdentifier.  

- max

> i would be a lot more incentivised

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Jul 2021 12:28:36 -0400

To add to your text

    > This leaf is "Optional since some serial-numbers are already unique
    > within the scope of a MASA” because, within the scope of a manufacturer
    > authorized signing authority that is truly provided by the manufacturer
    > one could reasonably expect the serial number to be unique. I mean,
    > what kind of manufacturer would sell multiple devices with the same
    > serial number? They’d just be shooting themselves in the foot.

Yet, it happens!
I bought 50 USB ethernet adapters (for RFC8994 work) via ali-express.
They arrived with Mac address 00:00:00:00:00:00 to 00:00:00:00:00:32.
Took me awhile to notice...

    > So the use case here is for a MASA servicing devices that might
    > plausibly have the same serial number; where "the statistically unique
    > key identifier ensures statistically unique identification of the
    > hardware”. This could obviously occur if a manufacture was, shudder,
    > re-using serial numbers. It is more likely to occur when the MASA is a
    > service authorized by the manufacturer that also handles multiple
    > manufacturers.

To need idevid-issuer one needs to have two things occur:

1) different sets of devices (such as from different branches), which share
   the same MASA Trust anchor.
   (if they have different MASA trust anchors, then no problem)
2) have overlapping serial-numbers.

The most obvious situation is mergers.  The MASA get merged.

Another situation is different branches, where one branch deployes a MASA,
and the other branch, which has been doing IDevID for awhile, realizes that
they can jump on board.

I guess that we need to make sure that we have some examples with
idevid-issuer so that we can test all code paths.

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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Jul 2021 19:52:56 +0200

Thanks, Max

My point was that reuse of serial number by e..: a MASA service supporting
multiple vendors is not a sufficient example why you would need this field.
The way i understand it, you would also need to assume that the two
devices with the same serial number have the same trust anchor against
which a voucher would be compared.

So, if for example the serial number is a bad format not well identifying the
vendor (VID/PID etc..), then the same serial number could happen across
different vendors served by the same MASA, but there would be no collision,
because these would have different TA.

I hope i correctly analyzed this.

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 ?
b) If not, can we create an example that sounds reasonable ?

   For example, i am manufacturing cheap low-end compuate, SBC or
   constrained CPU nodes (the like of ESP32 or so). These have an
   ethrenet interface but i sell too many to actually buy unique
   MAC addresses from IEEE. But still i thought it is a great
   idea for VID/PID to include model-type, but as the numeric
   component the ethernet-MAC, because i really didn't wan to have
   a unique identification (yes, i know this sounds stupid to me,
   but i am trying to come up with an example, and i have seen all
   type of stupid industry stuff).

   So, later on this security stuff gets added, BRSKI, voucher,
   devices have no reasonable insecure serial-numer, but their
   IDevID derived from such useless insecure serial number does
   have a unique differentiar,namely that KeyIdentifier.

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.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 26 Jul 2021 22:22:02 +0000

I shared my understanding of why the field exists and the language in existing docs supporting that understanding. As an optimist I hoped that manufacturers wouldn’t re-use serial numbers, although MCR followed up with examples, so I focussed on a rosy future where anima concepts are well established and a MASA service could be marketed to multiple manufacturers.

Between those two scenarios I think your suggestion of clarifying in RFC8366bis makes sense. Working group feedback could clarify if others feel it adds value or is unnecessary complexity.

- max

On Jul 26, 2021, at 11:52 AM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, Max

Cheers
   Toerless

On Jul 23, 2021, at 11:34 AM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

- max

Cheers
  Toerless

*** Question and context

*** Interpretation #1

*** Interpretation #2

Best regards
Esko

IoTconsultancy.nl<http://IoTconsultancy.nl>  |  Email/Teams: [email-masked]<mailto:[email-masked]>    |   +31 6 2385 8339

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

--
---
[email-masked]<mailto:[email-masked]>

--
---
[email-masked]<mailto:[email-masked]>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Jul 2021 00:31:33 +0200

Thanks, Max,

Michael: i don't remember an example from you where serial number would
be re-assigned. Can you remind me ? Oherwise maybe alk about it on thursday..

Thanks!
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2021 20:22:01 -0400

> 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.

    > so readers can understand why this differentiation by KeyIdentifier

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.