Trust Reset

[lann]

We have long discussed the possibility of a "trust reset" operation for a package which would allow the registry to assign a package to a new owner (key).

Use cases:

• Lost package maintainer private key(s)
  • In this case it may be desirable to maintain (or appear to maintain) package history across the trust reset, implying that the post-reset package log represents the "same package" as the pre-reset log.
• Legally-mandated transfer of control (e.g. trademark enforcement)
  • It may be desirable to not maintain continuity with the old package history because the new package maintainer may use the package name for entirely different content or consumers may want to re-evaluate their dependency in the context of the new maintainer.
• Reassignment of a package name after original package log deletion (e.g. name squatting, unacceptable data in package log itself)
  • In this case it may be undesirable for the new package to have any explicit association with the old one (though an implicit association would remain in the registry ledger)

Some hopefully-not-too-controversial requirements:

• Trust resets must be auditable. To some extent we get this "for free" by the nature of verifiable logs, but it could be enhanced with the addition of signed trust reset metadata (e.g. "reason" text and/or URLs to out-of-band communications about the reset).
• Trust resets would bypass certain aspects of the "low trust registry" security model warg has been designed around; because of this, any trust reset has to be presented as a "potentially dangerous" event to package consumers. If a trust reset represents a "continuation" of the package a consumer would need to take intentional action to accept that continuity.
• Trust resets should be "relatively rare" exceptional events. Because of the explicit user interaction requirement above, it's important that these don't become so commonplace that users are trained to mindlessly accept them.

I see two basic technical approaches to a trust reset (not necessarily mutually-exclusive):

1. A new "trust reset" package log entry type which would behave similarly to the "init" entry type, bypassing the normal log permissions checks and reinitializing part(s) of the log state; in particular this would at least grant one new key all permissions.
   • This is a natural way to represent the "lost private keys" use case as it inherently preserves log continuity, but may be a particularly bad fit for other uses cases where continuity is not wanted.
2. Allow a registry to update an existing package log ID to point at a new log starting at a new "init" entry. This could be paired with new optional fields in the "init" entry to record trust reset metadata.
   • This is a natural way to represent "this is a totally new package" but requires more client complexity to represent log continuity.
   • This could potentially serve other kinds of log-rewriting operations that have been discussed (protocol migrations, crypto algorithm updates, log compression)