Every Device shall have an “Initial Device Identifier” (IDevID) Certificate (see 802.1AR) that is used to prove the origin of the Device. This identity shall include a Private Key and an X.509v3 Certificate.

IDevID Certificate should have the ProductInstanceUri (see 5.2) as a uniformResourceIdentifier in the subjectAltName field (see RFC 5280). If the IDevID Certificate does not have the ProductInstanceUri the Device shall have an LDevID (Locally Significant Device Identifier) Certificate with the ProductInstanceUri in the subjectAltName.

If an LDevID Certificate is used it should be installed by the Manufacturer and signed by the Manufacturer CA. If the LDevID Certificate is signed by another organization, such as a Distributor, then this implies the other organization is trusted as an authority capable of assuring the origin of the Device.

The LDevID Certificate may use the same keypair as the IDevID Certificate. The Private Key should be placed in SecureElement storage on the Device.

The ProductInstanceUri should also be affixed to the Device in a form that allows electronic reading (e.g. RFID, QR code, bar code, et. al.).

The IDevID and LDevID Certificates shall conform to 802.1AR. The term DeviceIdentity Certificate is used to describe IDevID and LDevID Certificates that meet the requirements of this document.

The mechanisms for creating, installing, securing and revoking the IDevID and LDevID Certificates depend on the Manufacturer, however, Devices should provide a SecureElement storage (for an example, see ISO/IEC 11889) to ensure the associated Private Keys cannot be copied off the Device.

The IDevID and LDevID Certificates may have expiry dates that should be far in the future (802.1AR recommends the GeneralizedTime value 99991231235959Z in the notAfter field). The Manufacturer is responsible for creating the Certificate Authority used to issue the Certificates. Properly verifying the Certificates requires that the CA Certificate be acquired out-of-band via a mechanism that allows the receiver to authenticate the origin of the CA Certificate (see 6).

Any long-lived Certificate shall only be used for Device authentication during Onboarding stage (see Table 2).

Note that even if the IDevID or LDevID Certificate does not expire the CA Certificate could expire. When this happens, it is no longer possible to completely verify a DeviceIdentity Certificate. OwnerOperators need to be cautious and develop strategies to protect against risks created by these unverifiable Devices. Manufacturers should develop strategies to ensure these Certificates are verifiable for the expected lifetime of the Device.

The Ticket mechanism described in 6 includes the option to extend the validity period by adding Signatures created by trusted Certificate Authorities that have not expired.

ProductInstanceUri is a globally unique resource identifier assigned by the Manufacturer to a Device. This is often stamped on the outside of a physical component and may be used for traceability and warranty purposes. The identifier shall be a valid URI that meets the following requirements:

Have a length which does not exceed the limits imposed by the labelling technology chosen by the manufacturer;

Truly globally unique with a structure that enforces it.

Other standards, such as DIN 91406, define specific syntaxes that could meet these requirements.

Examples of ProductInstanceUris:

urn:some-company.com:5ff40f78-9210-494f-8206-c2c082f0609c

urn:some-company.com:model-xyz:snr-16273849

A Composite is a piece of equipment that contains a network of Devices. All of these Devices are internal to the Composite and can be accessed by other Devices within the Composite. Some of these Devices are also visible on an external network and have one or more Applications that need to be provisioned. Composites are an abstraction on a network and can only be physically accessed via one or more of the externally visible Devices.

A Machine is a common example of a Composite.

A Device which is visible on an external network may have an LDevID Certificate (see 802.1AR) created by the CompositeBuilder that can be used to prove the Device belongs to the Composite.

The CompositeInstanceUri is an identifier for the Composite assigned by the CompositeBuilder. All Devices in the same Composite shall have the same CompositeInstanceUri. The CompositeInstanceUri follows the same rules as ProductInstanceUri (see 5.2).

The subjectAltName is an array of alternate names for the Device. Each entry in the subjectAltName has a datatype and a value. An IDevID and LDevID shall have at least one URI name which is the ProductInstanceUri. LDevIDs created for a Composite shall have at least two URI names, the ProductInstanceUri and the CompositeInstanceUri. If a Device is in a Composite that is contained by another Composite, then only the outermost CompositeInstanceUri is present.

Note that the subjectAltName is a generic field that contains names used for purposes outside the scope of this specification. The URI names with the CompositeInstanceUri and ProductInstanceUri are identified by finding a Ticket that contains the values. URI names that cannot be matched to a Ticket are ignored.

Composites may contain other Composites and Devices. The contained Composite may be externally visible outside of the container Composite. In these scenarios, the CompositeBuilder may treat the contained Composites as Devices and add additional LDevID Certificates that identify the Devices as a component of the container Composite.

The additional LDevID Certificate has the Device ProductInstanceUri and the CompositeInstanceUri for the containing Composite.

The CompositeBuilder is responsible for installing and setup all Devices so they can interact with each other before the Composite is delivered.

When a Composite is connected to an external network it may be necessary to install and re-provision some of the Applications on each externally visible Device. This requires that additional Trust Lists be provided and new Certificates be issued to the Applications. CompositeBuilders may limit access to Applications running on the Devices and/or prevent management Applications on the external network from installing new Applications.

Each Client or Server on a network has a unique ApplicationUri. An ApplicationUri chosen by the CompositeBuilder may not be appropriate when the Composite is connected to the external network. For this reason, all externally visible Applications shall create their default ApplicationUri derived from the Device ProductInstanceUri which is specified in the subjectAltName field of the DeviceIdentity Certificate.