Inline, > On Jul 23, 2021, at 11:34 AM, Toerless Eckert <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 | Email/Teams: esko.d...@iotconsultancy.nl | +31 6 >> 2385 8339 >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > -- > --- > t...@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
