Hi!
The HTTP pin was removed years ago (800d731) because its reference backend stalled, but I hits a case where an HTTP escrow would be a better fit than tang.
Tang is binding: as long as a client can reach the tang server, it can decrypt. That's great for "boot a known-good fleet against known-good servers," but it means anyone who can reach the server gets the key — a leaked TLS cert, a compromised edge box, a misrouted VPN. No human involvement, no per-decryption audit.
Some times I want the opposite: escrow with explicit human approval. Reboot the box, get a push notification, tap Approve, key returns. Audit log of who approved what when. Same shape as tang but the recovery path is "a person decided" instead of "the network answered."
An HTTP pin that PUTs a JWK to a URL and GETs it back (with the backend gating the GET on human approval) fits that cleanly. It would also compose nicely with tpm2 inside SSS for hardware + human two-factor.
Worth reviving?
Hi!
The HTTP pin was removed years ago (800d731) because its reference backend stalled, but I hits a case where an HTTP escrow would be a better fit than tang.
Tang is binding: as long as a client can reach the tang server, it can decrypt. That's great for "boot a known-good fleet against known-good servers," but it means anyone who can reach the server gets the key — a leaked TLS cert, a compromised edge box, a misrouted VPN. No human involvement, no per-decryption audit.
Some times I want the opposite: escrow with explicit human approval. Reboot the box, get a push notification, tap Approve, key returns. Audit log of who approved what when. Same shape as tang but the recovery path is "a person decided" instead of "the network answered."
An HTTP pin that PUTs a JWK to a URL and GETs it back (with the backend gating the GET on human approval) fits that cleanly. It would also compose nicely with tpm2 inside SSS for hardware + human two-factor.
Worth reviving?