product-serial-number for discovery

[toerless]

a) I would like to see a real example, in appropriate appendix, ideally with format as of known LDevID. Alas, i have not manged to figure out if/what standards exist there. IMHO, an abstracted example of what Cisco does would be useful, e.g.:

X520SerialNumber = "PID:ANI-SDEV-7X9 SN:FBC1234X97A"

Aka: The serial number ("SN") component is unique only within the Product Series, and in this case the Product Identifier (PID) is ANI-SDEV-7X9. Note that PID does not include vendor identification, so this X520SerialNumber is not yet unique across vendors. This could still be a problem, although one could argue it should be unique enough...

b) I would highly recommend to say SHOULD use the product-serial-number exactly as encoded in the devices IDevID X520SerialNumber, with the OID tag id-at-serialNumber.

c) It would be good for someone beside myself to validate that the X520SerialNumber can without problems be encoded 1:1 as the DNS-SD Instance Name. The latter is Net-Unicode text [RFC5198] according to RFC6763, the X520SerialNumber is PrintableString according to rfc5280. This should be fine. It seems as if no UTF8 is needed at all to encode PrintableString...

d) I think we need explanatory text to argue for the encoding of X520SerialNumber, because rfc6763 explicitly says: the name should be a user-visible, user- friendly name rather than an invisible machine-generated opaque identifier, see Appendix C, "What You See Is What You Get".

Something like: For the intended use-case of the brski-pledge service, the Instance name MUST be a unique identification across all devices of the same type such that any individual instance of such device can explicitly be located. It also needs to be a unique name that can be known upfront by the automation system (registrar, registrar-agent) and potentially sales integration. The only name assumed to exist in most cases that fits these requirments is the IDevID X520SerialNumer. Note too, that this serial number is most often also printed on the device or its packaging, or can be constructed from information found there. In this respect, its use matches the expectations of [RFC6763, Section 4.1.1 and Appendix C].

[toerless]

Maybe a reference of interest: https://reference.opcfoundation.org/Onboarding/v105/docs/

[toerless]

Michael provided a certificate reconfirming the use of such structured serial numbers such as "PID:ANI-SDEV-7X9 SN:FBC1234X97A". Not sure yet, if we can copy the whole certificate publically here.

Example string would be : PID:ANI-SDEV-7X9\032SN:FBC1234X97A._brski-pledge._tcp.local

when useing the \032 escape for " " as used in rfc6763 example.

[mcr]

While this mDNS lookup works for the Cisco case that there is a vendor blob in the serialNumber, in general, I don't think it's enough. I think that it needs some bits from the AuthorityKeyIdentifier.

[toerless]

I fear that customers who buy devices from a vendor will not have a way to learn about the AthorityKeyIdentifier before they have been able to directly query the device. Which means we can not use it for e.g. discoverying the device vis any fnetwork discovery (DNS-SD, GRASP, CORE-LL, what have you).

What we do know customers will be able to learn from the sales system are the serial number and the product identifier. Both are printed on boxes and included in sales records.

Hence my worries that we should very strongly recommend that those two pieces of information are in the X520SerialNumber.

But ultimately we probably need to explain the above problem: Using information to find the device which a) can be known by customer of said device before discovering it over the network b) Sufficient unique to avoid falso positive.

[stfries]

Discovery of pledges by the registrar-agent is described in BRSKI-PRM section 5.3.2, Discovery of Pledge by Registrar-Agent What is missing here?

[stfries]

• General approach moved to BRSKI-Discovery (suggested text already in 01 of the BRSKI Discovery draft)
• Add service name(_brski_pledge) for BRSKI-PRM to section 8 similar as in RFC 8995 see https://www.rfc-editor.org/rfc/rfc8995.html#section-8.6
• to be discussed during IETF 118

[stfries]

As also discussed on the ANIMA mailing list, we decided to keep the discovery (endpoints, service names) in the basic version in BRSKI-PRM for now. The service name registration for pledge discovery by the registrar-agent is introduced with the next commit in a similar way as the service name for the registrar in RFC 8995. This is included as section 8.2.

[toerless]

As agreed upon in team and during IETF118, we will keep the text functionally as it is in this draft, doing improvements in brski-discovery. Possible editorial fixups unaffected.

[toerless]

Just looking for labels..and found.