Summary

  • On 24 September 2026, the IESG recorded “Approved No Problem” for the conflict review of draft-irtf-t2trg-taxonomy-manufacturer-anchors-21. It found related IETF work, but no relationship that prevented publication.
  • The document is an IRTF-stream Internet-Draft intended to be Informational. It expressly does not evaluate or numerically rank its five named IDevID manufacturing methods.
  • Avocado, Broccoli, Carrot, Squash and Spinach identify where key material is generated and which custody path it crosses. Assurance still requires evidence about entropy, factory exposure, seed transfer, CA control, anchor lifetime and device behaviour.

A narrow decision with a large risk of misreading

“Approved No Problem” looks unusually final on a status page. Here it answers a narrow question. RFC 5742 asks the IESG to review Independent and IRTF-stream work for conflict with IETF standards activity. In this case, the IESG said the taxonomy relates to work in ANIMA, LAMPS, TEEP, RATS and SUIT, but that the relationship does not prevent publication.

The decision does not say that the mechanisms are equally safe. It does not say that any factory follows them correctly. It does not convert an IRTF research result into an IETF standard. The Datatracker says the draft is not endorsed by the IETF and has no formal standing in its standards process. RFC 5743 likewise separates the IRTF stream from IETF products, while RFC 2014 states the older principle plainly: the IRTF does not set standards.

That institutional precision matters because this draft deals in terms that procurement teams may soon encounter. A supplier may say its device uses an Avocado or Spinach method. The label can make a design discussable. It cannot make the design trustworthy.

The draft itself refuses that promotion. Its purpose is to name mechanisms consistently, not evaluate them. It declines numerical ranking because human and process factors matter and points toward formal management processes such as ISO 27001. It is not Standards Track and contains no formal requirements language.

Five names, five different places for exposure

The memorable vocabulary is useful because it shows where the security problem moves.

In the Avocado method, the device generates its own private key in a protected environment. The key need never leave the device, but the device must have a credible entropy source. Its public key or certificate request still needs an integrity-protected route to the manufacturer's certification authority and a reliable binding to the serial number. After provisioning, the factory interface must be closed so that an attacker cannot return the product to an unconfigured state and substitute a new identity.

In Broccoli, factory infrastructure generates the key pair outside the device. Randomness and CA timing may be easier to manage, and the complete credential can be written with the firmware. The cost is a more valuable factory target: people or equipment may see the private key, and a network or mechanical transfer must deliver it to the correct device without disclosure or substitution.

Carrot begins with a unique secret seed installed by a silicon supplier. The device and a manufacturer system derive the same key pair; the manufacturer can obtain the certificate and destroy its private copy. This removes dependence on device-generated randomness, but it creates a supplier-specific seed inventory and a custody handoff. The draft calls secure transfer of those seeds to the device manufacturer the weakest link. Risk has moved into a smaller, more controlled facility and a sensitive delivery process.

In Squash, a Secure Element generates and contains the private key on the device. Extraction resistance is the architectural promise. That still leaves questions about the element's actual implementation, its integration, the public-key-to-serial binding, the CA and the lifecycle of the anchor.

In Spinach, the Secure Element supplier generates the key in its own factory. It may issue a supplier identity, operate a CA on the device maker's behalf or connect to the maker's CA. The device can request signatures without extracting the key. Yet trays of provisioned components become sensitive objects in transit, client-specific inventories must remain correct, and an activation mechanism has to break the bootstrap problem without creating a new universal secret.

None of these descriptions is a winner's podium. Each is a map of a different evidence boundary.

The certificate is not the manufacturing receipt

A valid IDevID can show that a CA signed a public key and identity statement. It cannot reconstruct how the corresponding private key came into being. The same certificate shape can follow from excellent on-device entropy, a copied factory key, a mishandled seed batch or a properly isolated Secure Element. The artefact proves the signature relationship; the production record must prove the path.

That record should bind a unit or batch to the claimed method, silicon and firmware versions, the public-key extraction or installation event, serial assignment, CA transaction and closure of manufacturing access. For Avocado it should preserve entropy-test and factory-lock evidence. For Broccoli it should establish private-key visibility, retention and transfer controls. For Carrot it should establish seed provenance, handoff, access and destruction. For Squash and Spinach it should identify the Secure Element, provisioning party, activation state and inventory reconciliation.

The draft then widens the aperture from device keys to the PKI that supports them. A CA can fail because its private key is disclosed, because legitimate operators lose access to it, or because it signs something it was not authorised to sign. An anchor fused into a long-lived product may be difficult to replace without a recall. A code-signing or revocation capability that disappears can strand a population even when no attacker stole a key.

This is why the evaluation questions matter more than the vegetable name. How many CA levels exist? Where is the root key stored? How often are subordinate keys retired? How are secret shares distributed? Which algorithms can the device use? How long must the anchor live, how can it be replaced, and what is each end-entity certificate allowed to sign? A supplier that answers only with the taxonomy has described the route while withholding the operating condition.

Vocabulary can remain thin without becoming empty

Heng Lu's distinction between symbolic and running layers gives the taxonomy its proper place. The conflict-review result is a process fact. The five names are vocabulary facts. The certificate is a configured artefact. A device that retains the key, rejects factory reprovisioning, validates the intended anchor and survives rotation or recovery tests supplies operational evidence.

The right response is not to dismiss the research document for refusing to certify products. A thin common vocabulary is valuable precisely because independent buyers and operators can ask comparable questions without granting the vocabulary authority it never claimed. The mistake would be to let publication or a memorable label stand in for voluntary adoption and observed behaviour.

Sources