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 <t...@cs.fau.de<mailto:t...@cs.fau.de>> 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 <t...@cs.fau.de<mailto:t...@cs.fau.de>> 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: esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl> | +31 6 2385 8339 _______________________________________________ Anima mailing list Anima@ietf.org<mailto:Anima@ietf.org> https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de<mailto:t...@cs.fau.de> _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de<mailto:t...@cs.fau.de>
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
