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.