Summary

  • RFC 9809 assigns distinct Extended Key Usage identifiers to configuration signing, trust-anchor configuration signing, update-package signing and safety-critical communication. The identifiers state certified purpose; they do not approve a particular artifact, peer, deployment or safety result.
  • The operative control sits in the chain around the certificate: issuer policy, application-specific combination rules, relying-party enforcement, object validation, accountable activation and observed outcome. A certificate carrying several legitimate purposes can still be unacceptable locally.

Imagine two certificates that validate to the same trusted root. The first carries only id-kp-updatePackageSigning. The second carries that purpose plus id-kp-trustAnchorConfigSigning. Both are unexpired, correctly signed and syntactically sound. The update service accepts the first and rejects the second.

Nothing in that result says the second certificate is counterfeit. The difference is policy. One key may authorize ordinary package releases inside a tightly bounded process; letting the same key change the roots of future trust could enlarge one compromise into control of every later verification. A relying party that separates those duties is not contradicting the certificate. It is completing the decision the certificate deliberately leaves open.

This is the governance problem behind RFC 9809, published on the Standards Track in July 2025. The document defines four X.509 Extended Key Usage, or EKU, identifiers:

  • id-kp-configSigning for signed configurations;
  • id-kp-trustAnchorConfigSigning for configurations that change trust anchors;
  • id-kp-updatePackageSigning for software or firmware update packages; and
  • id-kp-safetyCommunication for communication whose consequences can affect life, health, property or the environment.

The RFC Editor record identifies Hendrik Brockhaus and David Goltzsche as the authors and records the document's standards status. The IETF Datatracker preserves the IETF history. The IANA SMI registry supplies the durable public assignments under the PKIX key-purpose branch: 41, 42, 43 and 44.

That registry work is easy to underestimate. Before a common identifier exists, two systems can use certificates for the same purpose yet encode it differently, or reuse an overly broad purpose because no precise one is available. A stable OID lets certificate profiles, issuing systems, validation libraries and audits speak the same language. It makes a purpose machine-readable without forcing every application to invent a private marker.

But an OID is a named constraint, not a remote-control instruction.

RFC 5280 describes EKU as a restriction on the purposes for which a certified public key may be used. When both Key Usage and EKU appear, a use must be consistent with both. That creates two separate questions. Key Usage asks whether the key may perform a cryptographic class of operation, such as a digital signature. EKU asks what application purpose that operation may serve. Passing one does not waive the other.

RFC 9809 adds a third question: what combinations will the application accept? The four new purposes are not intrinsically mutually exclusive. The document leaves allowed and forbidden combinations to the relevant application standard and PKI certificate policy. This is not an omission to be repaired by guessing. A rail-control system, an industrial controller and a managed appliance may face different failure domains even when all three use the same registered names.

The issuer therefore owns only part of the control surface. A certification authority can verify a requester under its policy and place the appropriate EKU and Key Usage values in a certificate. It can refuse an overbroad request. It can publish the policy under which the assertion was made. It cannot know every relying party's deployment topology, maintenance window, separation-of-duties rule or appetite for combined authority.

The application community owns another part. A technical profile can require id-kp-updatePackageSigning, exclude id-kp-trustAnchorConfigSigning from the same leaf certificate, or permit a documented combination for a constrained device class. RFC 9336 provides a way to express permitted and excluded EKU policies in certification paths. The rule still has to be encoded and enforced by the software making the decision.

The relying party owns the last validation step. It must build and validate the path, check time and revocation policy where applicable, process Key Usage, require the intended EKU and reject a prohibited one. A library that merely asks whether the required OID is present can miss the dangerous half of the rule: an unwanted second purpose. anyExtendedKeyUsage is particularly weak here. It may be convenient for broad compatibility, but it makes deliberate purpose separation harder and RFC 9809 advises against using it as routine practice.

Even a perfect certificate decision does not approve the object. An update package still needs a target, version, dependency, freshness, rollback and payload decision. RFC 9019 separates firmware-update roles such as author, manifest author, distributor and device. RFC 9124 describes the information a manifest can bind to an update, including component and processing conditions. The EKU says what kind of signing the key was certified to perform. It does not fill the manifest, inspect the payload or establish that this device should install it now.

Configuration signing has the same boundary. A validly signed configuration can target the wrong fleet, refer to a retired interface, weaken a local safety limit or arrive after its change window. Trust-anchor configuration is more sensitive still: it changes which future assertions the system can accept. That is why RFC 9809 gives it a separate identifier instead of treating it as an ordinary configuration. The distinction creates an enforceable seam for dual control, offline approval, narrower key custody or a different rollback path. It does not create those controls automatically.

Safety-critical communication makes the gap between purpose and outcome impossible to ignore. A certificate may establish that a key was issued for a safety-sensitive communication purpose. The receiver must still authenticate the relevant peer and context, reject replay, check freshness and sequence, validate the message semantics and place the signal inside a system whose interlocks and fail-safe behavior are independently assured. An EKU can constrain who is allowed into that verification path. It cannot certify that a train stopped, a machine entered a safe state or a warning reached a human in time.

There is also a disclosure cost. EKU values reveal what a certificate is meant to do. RFC 9809 notes that certificates can be visible in TLS 1.2 exchanges and in public Certificate Transparency logs. RFC 5246 gives the TLS 1.2 protocol context; RFC 8446 encrypts TLS 1.3 handshake messages after ServerHello, including certificates. RFC 9162 defines the current Certificate Transparency framework. TLS 1.3 therefore reduces one observation surface, but it does not erase public logging, other protocol uses or internal inventory exposure.

That matters when a certificate identifies a system involved in safety communication or trust-anchor administration. Purpose specificity improves control and audit, yet may reveal operational function. The right response is not to blur every certificate with a universal EKU. It is to decide deliberately which certificate is public, whether public logging applies, how names are minimized, how keys are segmented and which observers need purpose evidence.

The clean audit record is a chain rather than a green check. It records the certificate fingerprint and path; issuer and certificate-policy identifiers; Key Usage and every EKU, not just the desired one; the application profile and combination rule; validation-library version and result; the signed object's identity, digest, target and freshness; the person or control that authorized activation; the rollout cohort and time; and the telemetry, canary or peer receipt that established the result. A rejection should name the violated rule just as precisely.

Heng Lu's Reality Layers supplies the discipline: registry meaning, certified claim, validation state, operational action and observed consequence occupy different layers. Running-Code Primacy puts the executable relying-party rule and real system behavior above a decorative policy diagram. Minimum Initial Specification explains why the four names can remain narrow while application communities make future combination choices locally.

RFC 9809 succeeds by refusing to pretend that the registry can govern every deployment. It gives four purposes stable names. A mature operator then makes each boundary visible: what the issuer asserted, what the application permits, what the relying party enforced, who authorized the action and what the system actually did.

Sources