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
On Mon, Jul 26, 2021 at 10:22:02PM +0000, Max Pritikin (pritikin) wrote:
>
> 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 protected]<mailto:[email protected]>> wrote:
>
> 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]<mailto:[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<http://IoTconsultancy.nl> | Email/Teams:
> [email protected]<mailto:[email protected]> | +31 6
> 2385 8339
>
> _______________________________________________
> Anima mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/anima
>
> --
> ---
> [email protected]<mailto:[email protected]>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
>
> --
> ---
> [email protected]<mailto:[email protected]>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
