X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, and Safety-Critical Communication
Extracted elements (20)
A separate id-kp-trustAnchorConfigSigning was defined rather than relying on id-kp-configSigning because trust anchor management is a particularly critical task; a device must only accept trust anchor configuration files verified by a certificate explicitly issued for that purpose, preventing misuse of general signing certificates.
None of the four new KeyPurposeIds are intrinsically mutually exclusive with each other; acceptable combinations with other KeyPurposeIds are deliberately left to the technical standards and certificate policies of the respective application and PKI, allowing flexibility across deployments.
The definitions of these KeyPurposeIds are intentionally broad to allow their use in different deployments (e.g., industrial automation, rail automation); the details for each deployment are left to the relevant technical standards and certificate policies rather than being constrained by this specification.
Vendor-defined KeyPurposeIds were rejected in favor of standardized identifiers because vendor-specific OIDs used outside their vendor-controlled environment or in critical EKU extensions lead to interoperability issues; standard KeyPurposeIds ensure interoperability across various vendors and industries.
Vendor-defined KeyPurposeIds used within a vendor-governed PKI do not pose interoperability concerns since non-critical extensions can be safely ignored if unrecognized, but using them outside their intended environment or in critical EKU extensions can cause interoperability failures.
A certificate requester MUST ensure that the Key Usage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and keyAgreement for key agreement, when requesting certificates containing these KeyPurposeIds.
If the certificate requester knows the certificate users are mandated to use these KeyPurposeIds, it MUST enforce their inclusion in the issued certificate.
Per RFC 5280 Section 4.2.1.12, if the EKU extension is present, the certificate MUST only be used for one of the purposes indicated; if multiple purposes are indicated, the application need not recognize all of them as long as the intended purpose is present.
Systems or applications that verify the signature of a configuration file, trust anchor configuration file, software or firmware update package, or the authentication of a communication peer for safety-critical communication SHOULD require that corresponding KeyPurposeIds be specified by the EKU extension.
The inclusion of the EKU extension in certificates may reveal the purpose of the certificate to observers; in TLS 1.2 certificates are exchanged in the clear, and even with encrypted transports (TLS 1.3), Certificate Transparency logs could allow an attacker to identify the certificate purpose and infer private information about the certificate subject.
Defines four new KeyPurposeIds for the EKU extension: id-kp-configSigning (OID { id-kp 41 }) for general-purpose configuration file signature verification, id-kp-trustAnchorConfigSigning (OID { id-kp 42 }) for trust anchor configuration file signature verification, id-kp-updatePackageSigning (OID { id-kp 43 }) for software or firmware update package signature verification, and id-kp-safetyCommunication (OID { id-kp 44 }) for authenticating communication peers in safety-critical communication.
id-kp-configSigning certifies a public key for verifying signatures of general-purpose configuration files of various formats (e.g., XML, YAML, or JSON) used to configure hardware or software.
id-kp-safetyCommunication certifies a public key for authenticating a communication peer for safety-critical communication based on TLS or other protocols, where safety-critical communication refers to communication that could lead to endangerment of human life, health, property, or environment.
id-kp-trustAnchorConfigSigning certifies a public key for verifying signatures of trust anchor configuration files used to add or remove trust anchors in a device's trust store; this is intentionally separate from id-kp-configSigning due to the critical nature of trust anchor management.
id-kp-updatePackageSigning certifies a public key for verifying signatures of software or firmware update packages, including bootloader, firmware, safety-related applications, and others installed on systems.
IANA registered ASN.1 module OID decimal 117 (id-mod-config-update-sc-eku) in the 'SMI Security for PKIX Module Identifier' registry [SMI-PKIX-MOD], referencing RFC 9809.
IANA registered four new OIDs in the 'SMI Security for PKIX Extended Key Purpose' registry [SMI-PKIX-PURPOSE]: decimal 41 (id-kp-configSigning), 42 (id-kp-trustAnchorConfigSigning), 43 (id-kp-updatePackageSigning), and 44 (id-kp-safetyCommunication), all referencing RFC 9809.
These EKU key purposes reduce existing security risks by providing means to identify if a certificate is scoped to a specific purpose, thereby mitigating cross-application attacks that could occur if a certificate with no EKU or broad EKU (e.g., id-kp-codeSigning) were accepted for trust anchor configuration or safety-critical communication.
To reduce cross-protocol attack risk, relying parties may prohibit use of specific combinations of KeyPurposeIds; the procedure for allowing or disallowing combinations using excluded and permitted KeyPurposeIds is defined in RFC 9336 Section 4. An example of a disallowed combination is anyExtendedKeyUsage together with any of the new KeyPurposeIds.
The KeyPurposeIds are encoded as OBJECT IDENTIFIERs under the id-kp arc { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }, with id-kp-configSigning at arc 41, id-kp-trustAnchorConfigSigning at arc 42, id-kp-updatePackageSigning at arc 43, and id-kp-safetyCommunication at arc 44. The EKU extension syntax is ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId.