Summary

  • On 24 September 2026, the IESG concluded that an IRTF taxonomy of manufacturer-installed keys and trust anchors is related to five IETF working groups but does not conflict with their work so as to prevent publication.
  • The draft names provisioning and custody methods, yet explicitly does not rank them or set security requirements. Its current record remains an Internet-Draft awaiting the IRTF's next publication step, not a numbered RFC.
  • That procedural clearance cannot establish which path a specific device class used, who controls its update-signing keys or what replacement path remains if an anchor is lost.

Consider an equipment buyer shown two documents. One lists “on-device key generation” as a named method. The other says the IESG has no problem with publication of the taxonomy that names it. Neither document says the equipment on the desk used that method. Neither identifies the people able to issue future firmware, or the route available if the signing authority disappears. The distinction matters because the first document is vocabulary and the second is a publication-process decision; neither is an inspection record for the device.

The IESG's 24 September response concerned draft-irtf-t2trg-taxonomy-manufacturer-anchors-21, an IRTF Thing-to-Thing Research Group document intended for the Informational RFC stream. The IESG found it related to work in ANIMA, LAMPS, TEEP, RATS and SUIT, but said that relationship does not prevent publishing. The announcement also asked the IRTF to examine comments in the Datatracker and decide whether to incorporate them. The draft record still identifies an active Internet-Draft and an IRTF state awaiting the chair after IESG review. “No problem with publication” is not the same event as publication of an RFC.

The boundary is built into RFC 5742. For an IRTF-stream submission, the IESG checks whether it conflicts with IETF standards work; the IRSG has responsibility for technical merits. The response used here is one of RFC 5742's specified outcomes for related work that can nevertheless publish. It is not an IETF standards-track approval, a device certification or a verdict on the strength of one factory's controls. The draft itself warns that it is not endorsed by the IETF and has no standing in the IETF standards process.

The taxonomy is valuable precisely because a label can make a hidden choice discussable. It distinguishes private keys generated on the device from keys created elsewhere and transferred, setup based on a seed, and variants involving a secure element. Those paths move custody and exposure to different places. It also distinguishes trust anchors by what they authorize: early boot, software updates, private services, onboarding and other roles. A public key anchored in a device is not one undifferentiated promise.

The draft identifies risks from replacing, adding, corrupting or removing an anchor, compromising its associated private key, and losing access to that private key without an attacker ever obtaining it.

That last case is a governance problem as much as a cryptographic one. The draft explains that a lost update-authorizing anchor can require physical service or replacement where remote replacement is impossible. It asks how long a manufacturer can sustain device-identity validation and whether signing-key custody can survive personnel or site disruptions. It does not assign scores to those answers, prescribe a winning architecture, request an IANA registry or claim any named device is unsafe. Its evaluation questions are a way to ask a manufacturer for evidence, not evidence that the manufacturer has supplied it.

A buyer or deployer could request a small, device-class-scoped anchor-custody receipt. It would name the relevant boot, update and onboarding roles; the provisioning method used for the class or batch; where the transition to a locked state is controlled; the accountable holder of manufacturer-side signing authority; and the versioned route for authorized rotation, recovery or replacement. It should identify the evidence owner, observation date, exceptions and who accepts residual risk. Sensitive private keys, individual device identities and factory-floor details need not appear in a public version.

This is an editorial proposal for accountable procurement and operation, not a requirement in the IRTF draft.

There is no reported breach or failed device behind this IESG action. Nor does it prove that every method in the taxonomy is equally safe. It creates room for a common language to be published. The people who design, buy and operate equipment still have to decide which claims are supported by records for the equipment they actually depend on.

Sources