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
On Fri, Jul 23, 2021 at 10:00:40PM +0000, Max Pritikin (pritikin) wrote:
> Inline,
>
> > On Jul 23, 2021, at 11:34 AM, Toerless Eckert <[email protected]> wrote:
> >
> >
> > 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,
>
> 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
> > 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.
> >
> > On Fri, Jul 23, 2021 at 03:30:39PM +0000, Esko Dijk wrote:
> >> 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.
> >
> > 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*.
> >
> >> 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 protected] | +31
> >> 6 2385 8339
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
> > --
> > ---
> > [email protected]
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/anima
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
