Remove Host Trust Manifests from v1 - #109
Open
jonathanhefner wants to merge 1 commit into
Open
Conversation
Limit `TrustManifest` to Catalog Entries and remove `host.trustManifest` from the normative prose, CDDL, data model, conformance rules, verification guidance, and authoring guides. A nested Host signature has no defined artifact subject, does not approve the surrounding catalog, and lacks a demonstrated Host-specific claim workflow. Record that rationale in ADR-0026 and leave operator authentication as a residual risk for the separate catalog-signature profile.
This was referenced Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The specification currently permits a Trust Manifest on either a Catalog Entry or a Host Info object, but defines the manifest and its verification in artifact-specific terms. In particular, a signed Trust Manifest requires a
subjectwhose media type and digest are verified against a containing Catalog Entry. Host Info has no corresponding artifact, media type, URL or data value, or bytes for a consumer to verify.This leaves no defined way to construct or verify the signed Host Trust Manifest permitted at Level 3. Signing only the nested manifest would protect its internal fields, but would not approve the surrounding Host Info, its placement in a catalog, or the catalog snapshot. The specification also defines no Host-specific claim vocabulary or independent consumption workflow that would justify that separate signature and lifecycle.
This PR removes
host.trustManifestand defines Trust Manifests exclusively as artifact-oriented companions to Catalog Entries. ADR-0026 records the decision and deferred alternatives. The normative prose, CDDL, data-model diagram, conformance rules, verification guidance, threat model, and author documentation are updated accordingly.Rationale
An Entry Trust Manifest has a concrete security purpose: its signed
subjectbinds publisher claims to an artifact that a consumer can retrieve and verify. Host Info instead identifies the operator of the catalog. Its integrity and association with a particular snapshot belong at catalog scope.The optional top-level catalog signature already covers Host Info as part of the catalog document. Once the catalog signer is independently authorized, that signature has the appropriate byte scope for authenticating the operator metadata together with the catalog it describes. A nested Host signature is neither a substitute for that catalog signature nor evidence that the Host approved the surrounding catalog.
Independently signed audit reports and organizational credentials can retain their native proof formats. A future profile may define how a catalog carries and evaluates such operator evidence after a concrete producer, consumer, verification procedure, and trust decision are established. Until then, implementations can incubate operator-specific evidence through
AICatalog.extensionswithout committing the core v1 model to undefined semantics.Scope
This PR does not change Entry Trust Manifest contents or verification. The separate release-coordinate binding proposal remains responsible for binding signed Entry Trust Manifests to logical artifact identifiers and versions.
This PR also does not repair the existing omission of the top-level
signaturefrom the normative CDDL or define how a catalog signature selects and authorizes a signer or verification key. The threat model now records catalog-operator authentication as a residual risk; completing the catalog-signature profile requires a separate decision.AI usage disclosure: This PR was developed with AI assistance under my direct supervision and review.