Summary

  • The OpenPGP Working Group opened an adoption call on 4 September for a draft that marks secret material as external and lets a Transferable Secret Key carry an optional locator hint. The call closes on 18 September; no adoption outcome is reported here.
  • The hint is advisory. A receiver may ignore an unknown hint or use best-effort discovery even when one is present. Revision 03 defines no particular hint scheme, and the live IANA registry does not yet contain the proposed External entry or locator-hint registry.
  • A portable stub can preserve cryptographic identity without preserving operational capability. Implementations should record local discovery, authorization, result and recovery evidence separately, without exposing sensitive device identifiers.

A transferable object with one deliberate absence

The call for adoption began on 4 September after discussion at IETF 126. It asks whether the OpenPGP Working Group should take on draft-dkg-openpgp-external-secrets-03, whose abstract is unusually literal: define a standard wire format indicating that the secret component of an OpenPGP asymmetric key is stored somewhere else, such as hardware or a comparable subsystem.

The call remains open until 18 September. The Datatracker record therefore carries two precise states: Call For Adoption By WG Issued for the Working Group and I-D Exists for the IESG. It also calls the document an active individual Internet-Draft and warns that it is not endorsed by the IETF. Supportive replies from Daniel Kahn Gillmor, Andrew Gallagher and Heiko Schäfer show engagement, not a ballot total or a completed consensus decision.

That unfinished process matters because the proposed format is unfinished too. Revision 03 tentatively asks for S2K usage octet 252, marked TBD, and for a new registry of locator hints. The live IANA OpenPGP registry currently lists the established Secret Key Encryption values but no External row at 252 and no External Secret Key Locator Hints registry. A draft request is not a live assignment.

What the stub actually carries

RFC 9580 defines the Secret Key packet and the Transferable Secret Key structure used to move OpenPGP key material among implementations. The new revision 03 would let the packet set its S2K usage octet to External. Instead of containing the secret parameters, the remainder may contain a hint about where an implementation might find a subsystem that can perform the secret operation.

The public part is essential. Best-effort discovery is expected to identify a device or subsystem by secret material corresponding to the associated public-key parameters. That gives a receiving implementation a cryptographic matching object. It need not trust a human-readable label such as “card in drawer three.”

But matching is not operating. The draft deliberately makes the locator hint advisory. If the hint is empty, the implementation uses best effort. If it does not understand the hint, or if the hint points nowhere useful, it may still probe the external mechanisms it supports. Even when a hint appears valid, the consumer may choose best effort instead.

Revision 03 does not standardize a single hint scheme. It proposes an initially empty IANA registry, reserves a private or experimental range and applies the Specification Required policy to other assignments. The packet creates an extensibility point, not a universal device address book.

A location hint is not a custody claim

It is tempting to read the stub as a forwarding address for the secret key. The draft resists that interpretation for good operational reasons. The same secret material may be available on multiple devices. The same device may acquire different physical identifiers when moved between machines. One implementation may know how to query a smartcard but not a platform TPM or remote HSM. A PKCS #11 URI can identify an object within that ecosystem, yet hard-coding every stub to a slot or serial would make some migrations less portable.

Best effort shifts the question from “What address did the packet assert?” to “What can this implementation observe here?” The answer is time-bound. A device can be absent, locked, disconnected or unsupported. It can list the corresponding public key but deny the requested secret operation. An authorization prompt may require a PIN, biometric gesture or button press. An operation may time out.

None of those results alone proves custody. A successful public-key match shows that a reachable subsystem advertises corresponding material. It does not identify the lawful owner, show who approved this operation or prove that no duplicate exists. A failed probe shows that this implementation did not obtain capability under these conditions. It does not prove that the secret was destroyed or never existed.

This distinction is especially important for organizations moving encrypted mail or signing operations between employee devices, service providers or recovery environments. Copying the OpenPGP stub may preserve the certificate and subkey references perfectly. The cutover can still fail because the capability lives outside the file.

Security benefit without a security fairy tale

External keys can reduce one class of exposure. Some devices do not release the secret, can rate-limit operations, demand a visible authorization action or attest that key generation occurred on the device. A removable token can let a user move capability without copying raw secret parameters to each host.

The draft does not market those properties as automatic. It notes that hardware can contain design flaws or yield to physical attacks. A compromised host can steal decrypted content or the symmetric session key even if it cannot extract the long-term secret. For signing, the device may confirm a button press while the compromised host supplies a different object from the one the user believed was being signed.

Usability is part of the security boundary. Repeated failed PIN attempts can lock some devices. Frequent authorization prompts may encourage unsafe caching or workarounds. Slow hardware, NFC taps and physical interaction require visible progress, sensible timeouts and actionable errors. An interoperable packet that produces opaque failures would standardize confusion, not control.

Gillmor’s adoption-call reply preserves that trade-off unusually well. He wrote that hardware devices are not a sensible choice for almost every OpenPGP user, while supporting a simple standard representation for people who do want them. Schäfer argued that some contexts effectively require hardware-backed material. The standardization question is not whether every user should adopt hardware. It is whether those who do can exchange an honest representation of what the file contains—and what it does not.

Keep the local evidence beside the portable object

The wire format should remain small. Loading custody policy, employment authority and recovery procedure into the OpenPGP packet would destroy the very portability the draft is trying to obtain. The missing operational evidence belongs in a separate external-key handoff receipt. This is my editorial proposal, not an IETF or OpenPGP requirement.

At minimum, a protected receipt can bind the certificate and relevant subkey fingerprint; the draft or later RFC version and actual codepoint state; the hint scheme and version if one was understood; the implementation and subsystem class it can query; the observation time; the public-key matching method; whether authorization was requested; the attempted operation; and the returned result or bounded error. A replacement or recovery event should link the previous observation to the new one rather than silently overwrite it.

The privacy limit is as important as the fields. Public reports do not need smartcard serials, HSM partition names, PIN histories, biometric data or internal topology. They can disclose an opaque receipt identifier, a capability class and a verified outcome while the responsible operator retains the sensitive record under access control.

The receipt must never turn a locator into authority. It records that a particular implementation obtained or failed to obtain a particular capability at a particular time. Ownership, permission to sign, retention duties and recovery approval still come from the relevant organization and law.

Heng Lu’s Policy Mirror is useful here because it separates an actor, a rule and evidence rather than letting a technical artifact stand in for all three. The Minimum Initial Specification favours a compact shared core with localized extensions. In this case the shared core is the portable OpenPGP signal; local operational evidence stays attached without pretending to be part of the global wire format. Why BTW Media Exists supplies the reporting discipline: describe the draft, call and current registry as they are, not as advocates expect them to become.

The draft’s most valuable honesty is the word “external.” It says the transferable record is not the whole capability. A standard can make that absence legible. Only local evidence can show whether the missing part is available when the next operation arrives.

Sources

  1. OpenPGP Working Group call for adoption
  2. Current Datatracker record
  3. OpenPGP External Secret Keys, revision 03
  4. IETF 126 presentation
  5. Daniel Kahn Gillmor’s adoption reply
  6. Andrew Gallagher’s adoption reply
  7. Heiko Schäfer’s adoption reply
  8. Paul Schaub’s co-editor reply
  9. Live IANA OpenPGP registry
  10. RFC 9580 — OpenPGP
  11. RFC 8126 — Guidelines for Writing an IANA Considerations Section
  12. RFC 7512 — The PKCS #11 URI Scheme
  13. Heng Lu — The Policy Mirror
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Why BTW Media Exists