# AEF 1101: The Trust Base ## What verification rests on, how it is stated, and what cannot be claimed about it **AEF 1101. Version 0.1. Published 11 August 2026.** ## 1. Status AEF 1101 v0.1 is an early draft and will change. It is the fourth document in the series and the second in the 1100 block. This document is partially normative, which distinguishes it from AEF 1001 and AEF 1100. Sections 6, 7, 10, 11, and 12 carry requirements. Every other section is analysis. Requirements are marked by their subject: a requirement on an implementation binds a system that produces attested execution records, a requirement on a trust base statement binds that artifact, and a requirement on a verification result binds the output of a verifier. Where the analysis implies something a verifier must do, it points to AEF 1200 rather than imposing it here. AEF 1000 is the source of authority. AEF 1001 supplies the vocabulary, used exactly and not redefined. AEF 1100 supplies the threat analysis this document answers to, cited by threat id. Versions are dated, kept at their own paths, and recorded in CHANGELOG.md beside this document. ## 2. Why this document exists AEF 1000 principle 2 requires that verification not depend on the operator, and that every remaining trust dependency be external to the operator, enumerated, and stated with what fails if that trust is misplaced. The enumeration half is checkable by inspection. What it left open is what counts as one dependency, and whether a stated trust base is candid or merely present. Both are worse than they look. An implementer satisfies enumeration with one line saying the platform is trusted, or with four hundred lines naming every library in the process, and nothing in the framework distinguishes either from an honest accounting. A requirement that any answer satisfies is not a requirement. This document supplies the unit, the form, and the tests that make principle 2 enforceable, and it says plainly where it fails to. ## 3. Normative language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in all capitals. ## 4. What this document owes the series Three documents deferred five questions here. Their disposition is stated at the top rather than discovered at the bottom. **Settled.** What a stated dependency must contain, in section 6. What external means, in section 7. What an independent key history must provide, in section 10. Whether a verification result must record the trust base in force, in section 11, which answers AEF 1100 threat 9.4. **Settled by replacement.** Irreducibility, assigned here by AEF 1000 principle 2 and recorded as AEF 1001 open question 5. Section 8 concludes that irreducibility is not a claim anyone can make, and replaces the requirement with one that is checkable. **Partially settled.** What establishes a key, AEF 1001 open question 4, in section 9. The distinction between identity and continuity of use is settled. Which mechanism an implementation must use is not, because the answer depends on what a given reviewer can reach, and section 9 states that dependency rather than resolving it. **Deferred again.** None. Every question assigned here receives an answer in this document, including the answer that one of them was the wrong question. ## 5. What a trust dependency is ### 5.1 Individuation is by party, not by component A trust dependency is a party who could cause verification to accept a record it should reject, or reject one it should accept, if that party chose to. The unit is the party rather than the component, because the reviewer's question is who can lie to me, not what software sits in the path. A list of libraries answers a question nobody asked and obscures the one that matters. Two components under one party's control are one dependency. One component under split control, such as a signature requiring shares held by two parties, is two. Where a single party controls several mechanisms whose failures differ materially, the failure modes are enumerated under that party rather than split into separate dependencies. A vendor supplying both a hash implementation and a signature implementation is one party with two ways to be wrong, and the record says so. This resolves both failure modes named in section 2. A single line naming the platform fails, because a platform is not one party: the platform operator, the certificate authority, the time source, the operating system vendor, and the hardware vendor are distinct parties, each independently capable of defeating verification. Four hundred lines of components also fails, because it does not name parties at all. The test a reader can apply is whether the statement answers the question who could cause this to be wrong. ### 5.2 Composition is the transitive closure, with a declared cut-off Dependencies compose. A key is established by a certificate authority, which is established by a root, which is distributed by an operating system vendor, which is compiled by a toolchain. Every party in that chain can defeat verification, so the trust base is the transitive closure of parties, not the frontier. A frontier reading would let an operator name its immediate dependency and conceal the chain behind it, which is the same move AEF 1100 threat 7.1 identifies at the level of scope. The closure does not terminate. It runs through compilers, silicon, and physics, and Thompson's reflection on trusting trust is the canonical statement of why that regress is structural rather than an implementation failure. A statement that tried to be complete would be infinite and useless. The resolution is the one AEF 1000 principle 3 already supplies for records. A trust base statement declares where the closure was cut and why, and completeness is assessed against that declaration rather than against the world. A statement with no declared cut-off is neither complete nor incomplete, because there is nothing to test it against. A statement that declares its cut-off can be argued with, which is the most this framework asks of anything. ## 6. The dependency record Requirements in this section bind a trust base statement. A trust base statement MUST contain, for each dependency: - **What is trusted.** The specific assertion or behaviour relied on, not the party's name alone. A certificate authority is not trusted generally; it is trusted to have bound this key to this identity and not to have issued a second binding for the same identity. - **Who controls it.** The party that could change or withdraw the assertion, named specifically enough that a reviewer could contact or audit them. - **What fails if the trust is misplaced.** The consequence, stated as an outcome rather than a category. AEF 1000 principle 2 already requires this; it is restated here because the record is where it lives. - **Whether it is external to the operator**, determined by the test in section 7, with the answer stated rather than implied. A trust base statement MUST declare where the transitive closure was cut, per section 5.2, and SHOULD state why the cut falls there. The controlling party field is the one that does the real work, and it is the one an operator is most tempted to state vaguely. "A public timestamp authority" names no party. "An industry-standard certificate authority" names no party. A reviewer who cannot identify the party cannot assess whether it is external, cannot assess whether it has an interest in the outcome, and cannot check whether it is the same party as another entry. Vagueness in this field defeats the other three. A statement whose controlling party fields do not name identifiable parties does not satisfy this section, however complete it appears. ## 7. Externality Requirements in this section bind a trust base statement. AEF 1000 principle 2 requires dependencies external to the operator, and does not say what external means. Legal separateness is the obvious reading and the wrong one. A vendor the operator pays, a platform the operator's infrastructure runs on, and a timestamp authority the operator selected are each nominally third-party and variably independent. This is where most real trust bases will fail honestly and pass nominally. A dependency is external to the operator only if all three of the following hold. A trust base statement MUST record the answer to each. **One. The operator cannot alter what the party asserts, acting alone.** If the operator can change the assertion without the party's participation, the party is a conduit rather than a dependency, and verification depends on the operator through it. **Two. The operator cannot cause the party to withdraw the assertion.** A party that stops asserting on the operator's instruction, or on the operator ceasing to pay, gives the operator a retraction it can exercise at will. This is AEF 1100 threat 10.2 generalised beyond keys: any withdrawable assertion is a repudiation tool. **Three. A reviewer can obtain the party's assertion without the operator's cooperation.** An assertion reachable only through the operator is external in form and useless in fact, because the operator selects which assertions the reviewer sees. This is AEF 1100 threat 6.7 applied to the trust base. Most real dependencies pass the first test and fail one of the others. A commercial certificate authority typically passes one and three and fails two, because a subscriber can decline to renew. A cloud platform hosting the records typically passes one and fails three. Stating the three answers separately, rather than a single external yes or no, is what makes the difference visible, and a statement that collapses them to a single flag SHOULD be read as not having done the analysis. ## 8. Irreducibility AEF 1000 principle 2 dropped the requirement that a trust base be minimal, on the grounds that no base could be shown to violate it, and assigned irreducibility to this document. This section concludes that the assignment cannot be discharged as posed, and states what replaces it. A candidate framing is that a dependency is reducible if a construction exists that removes it without adding a larger one. That framing has two defects, and the second is fatal. The first is that it presumes an ordering on trust bases, and there is none. Whether trusting one certificate authority is larger or smaller than trusting two independent logs is not a question with an answer. Bases differ in shape, not only in size, so comparison is a partial order at best. Reducibility is therefore well defined only in the narrow case of a strict removal: a construction that eliminates a party and adds none. The second defect is that irreducibility, even narrowed to strict removal, is a negative existential over the literature. To assert that a base is irreducible is to assert that no construction exists anywhere that removes one of its parties. Nobody can establish that. The claim is not merely time-indexed, though it is that too; it is not a claim that can be made at all, by anyone, at any date. What can be demonstrated is the positive: that a construction does exist. Reducibility is provable by exhibiting a construction. Irreducibility is not provable by anything. **What replaces it.** A trust base statement SHOULD contain a reduction statement: for each dependency, whether the author knows of a published construction that would remove the party without adding another, and where one is known, why it was not used. Cost, latency, and operational reach are acceptable reasons. Absence of an answer is not. This is checkable by inspection, which is what principle 2 asks of everything else in this document. Either the reduction statement exists or it does not. It is also falsifiable by exactly the right party: a reviewer who knows a construction the author did not cite has found a defect, and the defect is in the statement rather than in the base. That converts an unprovable negative into a citable positive, and it makes the state of the art someone else's contribution rather than the author's assertion. The consequence for AEF 1000 principle 2 is that dropping minimality was correct and did not go far enough. Minimality was not merely untestable pending this document. It is untestable in principle, and this document says so rather than leaving the impression that a later version will supply what was missing. ## 9. Establishing a key This section answers AEF 1001 open question 4, partially. A bare signature establishes continuity of use: the same key signed both records. It establishes nothing about whose key it is. AEF 1001 section 6.9 already states that a signature verified against a key nobody can attribute establishes only that the same key was used twice. Identity requires two things, and mechanisms that supply only the first are the common case. **An assertion by a party other than the operator** that this key belongs to this identity. **A mechanism by which that party's equivocation is detectable**, meaning a way to tell that the asserting party has bound the same identity to a different key for a different audience. Existing work supplies these and this document does not reinvent it. What follows names the mechanisms and what each asks of the reviewer, which is the part that matters for a trust base statement. **Public key infrastructure in the X.509 sense** supplies the assertion. A certificate authority binds a key to a name. The reviewer must hold the authority's root, must check revocation at verification time, and gains no way to detect misissuance. The authority is a dependency under section 5.1 and typically fails externality test two under section 7. **Certificate Transparency**, in the sense of RFC 6962, adds detection. Certificates are submitted to append-only logs and carry proofs of that submission, so misissuance becomes discoverable after the fact. The reviewer must be able to reach a log and check an inclusion proof, and the detection is only realised if somebody monitors the logs, which is a party the statement should name. **Key transparency**, in the CONIKS line of work and its later deployments, applies the same construction directly to identity-to-key mappings rather than to certificates. It adds consistency proofs, so an operator showing different keys to different reviewers is detectable rather than merely discoverable. The reviewer must check inclusion and consistency proofs and must have some way to compare what they were shown against what others were shown. **Out-of-band pinning**, where the reviewer holds the key directly, removes the third party entirely. It does not scale, does not survive rotation, and is nonetheless the strongest option when it is available. A trust base statement whose key binding is a pin has a smaller base than one whose binding runs through an authority, which is a reduction under section 8 worth stating. **What this document settles.** Identity requires an assertion plus a detection mechanism for the asserter. A trust base statement whose key binding relies on assertion alone MUST say so, because a reviewer reading "certificate authority" will otherwise assume a detection property that is not present. **What it does not settle.** Which mechanism an implementation must use. That depends on what a given reviewer can reach, and a requirement naming one mechanism would fail for reviewers who cannot query the log it names. The dependency is stated rather than resolved, and AEF 1200 will state what a verifier must check once the mechanism is known. ## 10. Key history Requirements in this section bind an implementation. AEF 1100 threat 10.2 identified operator-controlled key history as a repudiation tool: rotate, decline to publish the retired public key or assert that it was compromised, and every earlier record becomes unverifiable or deniable at the operator's discretion. AEF 1100 threat 10.1 identified the related exposure, that a compromise reaches backward through every record a key ever sealed unless seal times are anchored independently. An independent key history MUST provide: - Which keys were valid over which intervals, with interval endpoints that do not depend on the operator's clock. - Publication in a place the operator cannot retract from. - Availability to a reviewer without the operator's cooperation, per section 7 test three. - Its own controlling party, disclosed as a dependency under section 6. **On append-only public logs.** They are the best current option and not the answer, and the difference matters. They are the best current option because the log operator's misbehaviour is detectable and the operator's is not. A log that equivocates can be caught by comparing consistency proofs across observers. An operator that rewrites its own key history cannot be caught by anything. Trading an undetectable failure for a detectable one is a real improvement and is the whole argument. They are not the answer for three reasons, all of which a trust base statement MUST record when a log is used. The log operator becomes a dependency, so the base has traded a party rather than removed one, and section 8 requires that to be stated as such. Append-only is a property somebody must monitor for, not one the log confers by existing, and the monitoring party is itself a dependency. And the log must be reachable at verification time, which makes availability a liveness dependency that a verification years later may not satisfy. ## 11. Trust base recording in verification results Requirements in this section bind a verification result. This section answers AEF 1100 threat 9.4. AEF 1001 section 9 holds that verification time is evidence that a record verified at that moment under the trust base then in force. AEF 1100 threat 9.4 observed that no verification result records the trust base, so the conditions of the check are unrecoverable and verification time is evidence of less than AEF 1001 claims. A verification result MUST record: - The identity of the record verified, bound by cryptographic hash rather than by name. - The verification time, and the time source that supplied it. - The trust base statement in force at verification, in the form section 6 requires, either inline or by hash reference to a retrievable statement. - The identity and version of the verifier, per AEF 1001 section 6.11. - The outcome, and where the outcome is a rejection, which check failed. A verification result that omits the trust base is not a conformant verification result under this document, whatever it says about the record. This is the most concrete deliverable in this document and the one most likely to be implemented first, because it requires no new infrastructure. It is a change to what a verifier writes down. ## 12. Re-verification under a changed base Requirements in this section bind a verification result. A trust base changes. Keys rotate, certificate authorities are distrusted, algorithms are deprecated, log operators shut down. AEF 1001 section 9 defines re-verification as a verification performed later, particularly after such a change. What that later verification means requires a distinction the series has not drawn. **A record that no longer verifies** has failed cryptographically. The bytes do not check. This case is loud and needs no help. **A record whose verification is no longer meaningful** still checks. The verifier reports success. What has changed is the standing of a party the check rested on: the authority that bound the key has been distrusted, or the key was later compromised, or the algorithm has been broken since. The result is a pass that a reviewer should not rely on, and nothing in the output distinguishes it from a pass they should. The second case is the dangerous one, because the failure is silent and the report is green. A re-verification result MUST compare the trust base in force at re-verification against the trust base recorded in the earlier verification result, and MUST report every difference, including a dependency that has been withdrawn, a controlling party that has changed, and a mechanism that has been deprecated. A re-verification that does not carry that comparison is a second verification with no memory, which is not what AEF 1001 means by the term. Whether a difference invalidates the earlier conclusion is a judgment for the reviewer. Surfacing the difference is the framework's obligation. AEF 1200 will state what a verifier must do to perform the comparison. ## 13. The reference implementation's trust base AEF 1001 section 7.1 concedes that the author of this framework also writes its reference implementation, so the verifier has no adversary in its history. That discipline is followed here by stating what the author's own system asks a reviewer to trust, including the entries that are uncomfortable. The system in question produces cryptographically signed act-log bundles for agent runs, with a verifier built as a hostile target, as AEF 1000 section 1 describes. Parties are individuated per section 5.1 and the closure is cut at the hardware vendor, per section 5.2, because below that line the author has no visibility and would be enumerating categories rather than parties. | # | What is trusted | Controlling party | If misplaced | External | |---|---|---|---|---| | 1 | That the sealing key was held only by the signer | The operator | Any record can be forged or repudiated at will | No | | 2 | That the key binding names the right party | Key binding authority, to be named by the editor | Records verify against a key belonging to someone else | Partly | | 3 | That recorded times reflect real time | Time source, to be named by the editor | Every recorded time is an assertion, per AEF 1100 threat 10.3 | Partly | | 4 | That the verifier a reviewer runs is the verifier published | The operator, today | A reviewer runs the operator's program, per AEF 1100 threat 9.3 | No | | 5 | That golden fixtures cover the cases that matter | The author | The verifier passes everything anyone thought to test, per AEF 1100 threat 9.2 | No | | 6 | That the signature and hash implementations are correct | Cryptographic library maintainers | Forgery or collision goes undetected | Yes | | 7 | That the language runtime executes the verifier as written | Runtime maintainers | The verifier's behaviour differs from its source | Yes | | 8 | That the build toolchain compiles the verifier as written | Toolchain maintainers | Thompson's attack, and nothing in the record detects it | Yes | | 9 | That stored bundles remain retrievable and unaltered at rest | Hosting party | Records are lost or withheld, per AEF 1100 threat 11.2 | Partly | | 10 | That the hardware executes instructions as specified | Hardware vendor | Everything above is void | Yes | Ten parties. Five are external under all three tests in section 7. Three are the operator or the author and are external under none: the sealing key, the verifier a reviewer actually runs, and the fixture set. Two are partly external, passing test one and failing test three, meaning a reviewer currently reaches them through the operator. The three uncomfortable entries are 1, 4, and 5. Entry 1 is structural and every signing system has it. Entries 4 and 5 are not structural and are the framework's own unmet requirements, which section 14 states. Entries 2 and 3 name a party the editor has not yet published. That is a gap in this worked example rather than in the form, and it is recorded in section 17 as work owed before v0.2. A worked example with an unnamed controlling party fails section 6 by its own test, and stating that is more useful than filling the cell with something plausible. ## 14. Requirements the reference implementation currently fails A framework whose author's own system fails its requirements is honest. One that quietly sets requirements it already meets is a description rather than a standard. The reference implementation fails four requirements in this document. Section 6: it publishes no trust base statement at all, so it satisfies none of the dependency record requirements. Section 10: it has no independent key history. Key rotation would be a repudiation tool exactly as AEF 1100 threat 10.2 describes. Section 11: its verification results do not record the trust base in force, which is the requirement this document calls the most concrete and the most likely to be implemented first. It is not implemented. Section 12: it performs no comparison at re-verification, because there is no recorded base to compare against. Section 13 entries 4 and 5 are the same failures viewed from the other side. ## 15. Terms used here that AEF 1001 does not define Recorded rather than coined silently, following AEF 1100 section 16. Each belongs in AEF 1001's next version. - **Trust base statement.** The artifact section 6 defines. AEF 1001 defines trust base as a set of dependencies and gives that set no written form. - **Verification result.** The output of a verifier as an object. AEF 1001 section 9 defines verification time without defining the thing that carries it. - **Controlling party.** The party that could change or withdraw an assertion, which section 5.1 makes the unit of individuation. - **Reduction statement.** The artifact section 8 substitutes for a minimality claim. Still undefined from AEF 1100 section 16 and used here: time source and key history. This document states what a key history must provide without AEF 1001 having defined what one is, which is the wrong order and is recorded as such. ## 16. Requirements with no observer The defect class audited in AEF 1000 and AEF 1100, applied to this document's own requirements. Section 6's closure cut-off must be declared, and nothing tests whether the cut falls somewhere defensible. An operator can cut above the interesting parties and satisfy the requirement. Section 6's controlling party field must name identifiable parties, and identifiable has no threshold. "A major cloud provider" is more specific than "the platform" and still names nobody. Section 7's three tests are answered by the operator about its own dependencies, with no party designated to check the answers. An operator that believes its vendor is independent will record that belief. Section 8's reduction statement asks whether the author knows of a construction. Not knowing is always available and is not falsifiable except by a reviewer who happens to know better, which makes enforcement depend on the audience rather than on the record. Section 13's completeness is self-certified. The reference implementation's trust base is complete because the author says it is, which is the same defect this document identifies in section 6 and does not escape. Sections 11 and 12 are the exceptions. Both are checkable by inspecting a verification result, and a result that omits the trust base or the comparison is visibly non-conformant to anyone holding it. That is the difference between a requirement on an artifact and a requirement on a judgment, and it is why section 11 is the one likely to be adopted. ## 17. Open questions 1. **Naming the key binding authority and time source for the reference implementation.** Section 13 entries 2 and 3 are incomplete by this document's own test. Owed before v0.2 of this document. 2. **What makes a closure cut-off defensible.** Section 5.2 requires the cut to be declared and cannot say where it should fall. No document assigned; it belongs in a later 1100-block document. 3. **Whether externality admits degrees rather than three binary tests.** Section 7 treats a partial pass as a fail with the details recorded, which may be the wrong shape. AEF 1101 v0.2. 4. **How a verifier performs the section 12 comparison**, including what counts as a difference and what a deprecated algorithm means for a record sealed before deprecation. AEF 1200. 5. **Whether a reduction statement should carry citations rather than assertions.** Requiring a citation would make section 8 falsifiable by reference rather than by expertise, at the cost of being harder to satisfy honestly. AEF 1101 v0.2. ## 18. License and citation Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Cite as: > Stellmacher, G. (2026). *AEF 1101: The Trust Base*, v0.1. 11 August 2026. https://grantstell.com/aef/1101 Cite the version and date, always.