Hardware-Rooted Attestation Tokens for Electricity Generation

2.1. Terms

Attester:

A metering device, paired with a secure element, that produces attestation tokens. This aligns with the Attester role in the RATS architecture [RFC9334].¶

Verifier:

A role that appraises Evidence about an Attester, using Endorsements, Reference Values, and appraisal policy, and produces Attestation Results, as in [RFC9334]. In this document the appraisal also covers the Merkle inclusion proof and on-chain commitment of an attestation token.¶

Relying Party (RP):

A role that depends on the validity of information about an Attester, as conveyed in Attestation Results, as in [RFC9334]. Examples include producers, consumers, regulators, and integrators of clean-energy claims.¶

Endorser:

An entity that issues an endorsement linking a device's public key to a real-world identity, such as a manufacturer, a certification authority, or a self-attested operator.¶

Reference Values:

The expected device configuration digest, firmware version, and model against which Verifiers may assess an Attester. Properties such as certification status are Endorsements, not Reference Values.¶

Attestation Result:

The output of a Verifier's appraisal of an Attestation Token, as defined in [RFC9334]. In this document it is encoded as an EAR (Section 8).¶

Attestation Token:

A CBOR-encoded COSE_Sign1 object carrying the signed measurement and ancillary claims.¶

Evidence Payload:

The CBOR claims map carried inside an Attestation Token, as defined in Section 4.1.¶

Settlement Layer:

A publicly accessible verifiable data structure on which Merkle roots of attestation batches are committed. In this version, the Settlement Layer is an EVM-compatible Layer 2 rollup; future revisions MAY broaden this.¶

Batch:

An ordered collection of attestation tokens whose hashes form the leaves of a single Merkle tree.¶

Epoch:

The sequence number identifying a batch in time. Epochs increase monotonically.¶

Challenge Window:

A configurable period following batch submission during which the batch can be challenged before finalization.¶

Measurement Interval:

The time interval to which the energy delta of an attestation token applies, derived as specified in Section 9.¶

NOET:

The attestation accounting unit of the protocol. One NOET represents one verified kilowatt-hour. NOET is a unit of attestation, not a payment instrument, a currency, or a store of value; this document specifies no transfer, pricing, or settlement-of-value semantics for it.¶

3.1. Attester

The Attester is composed of two physical components: a kilowatt-hour meter (the measurer) and a secure element (the signer). The Attester:¶

• MUST generate the device's signing key inside the secure element using on-chip entropy.¶
• MUST NOT permit the signing key to leave the secure element under any operational condition.¶
• MUST sign each evidence payload with the device's private key, as a COSE_Sign1 structure (Section 5.1), before transmission.¶
• MUST include in each attestation the "prev" claim (Section 4.1), a hash of the previous attestation produced by the same device, forming a per-device hash chain.¶
• MAY include firmware version, model identifier, and configuration claims in the attestation token.¶

3.2. Verifier

The Verifier is software, executed by any interested party, that:¶

• MUST validate the COSE_Sign1 signature of the attestation token, as specified in Section 5.1, using the Attester's endorsed public key, and MUST reject any token whose protected header names an algorithm the Verifier does not accept.¶
• MUST verify the Merkle inclusion proof against the on-chain committed root for the corresponding epoch.¶
• MUST check the endorsement chain of the Attester's public key against a trusted Endorser registry.¶
• MAY apply additional Reference Values checks (firmware version, model, certification status) where required.¶
• SHOULD, when its appraisal is conveyed to a Relying Party, encode the Attestation Result as specified in Section 8.¶

3.3. Relying Party

The Relying Party consumes attestations and acts on them. A Relying Party:¶

• MUST independently invoke a Verifier, either as a library or as a service; it MUST NOT rely on an Attester's self-report alone.¶
• SHOULD apply use-case-specific validity criteria beyond signature verification, for example timestamp freshness or jurisdiction.¶

3.4. Endorser

An Endorser issues an endorsement binding a device public key to identity metadata such as manufacturer, model, and certification batch. Endorsers:¶

• MUST publish their own public key in a manner that is itself verifiable, such as an X.509 certificate, a well-known DNS record, or an on-chain registry.¶
• SHOULD specify the procedure by which they obtain assurance that a given public key originates from a tamper-evident secure element.¶

Endorsements and Reference Values MAY be conveyed using CoRIM as described in Section 7.2, or through the registry options of Section 7.1.¶

This document does not mandate a single Endorser hierarchy. A federation of Endorsers is expected to emerge in practice; relying parties choose which Endorsers to trust.¶

3.5. Validator

The Validator is an on-chain role responsible for confirming Merkle root submissions before they are finalized for claim. Validators extend the RATS architecture; they exist because the on-chain commitment layer requires a defined set of accountable parties whose signed actions are the basis of finalization. A Validator:¶

• MUST hold the validator role granted by the holder of the settlement contract's administrative role. Production deployments place that administrative role in a multi-signature wallet.¶
• MUST independently verify the Merkle root it is voting on against its own reconstruction of the underlying leaf set before broadcasting a batch proposal or a vote. A Validator that votes without independent verification is a single point of trust and defeats the m-of-n property the quorum is designed to provide.¶
• SHOULD publish its identity (operator, jurisdiction, and contact) so that fraud-proof challengers and relying parties can attribute votes.¶
• MAY be operated by the standards body, by a delegated operator, or by an independent third party. The m-of-n design treats Validators as Byzantine-tolerant peers, not as trusted authorities.¶

Validator accountability is enforced through two mechanisms whose details appear in Section 10.4:¶

1. Quorum. No single Validator can cause finalization on its own; the m-of-n threshold ensures that a minimum of "threshold" distinct Validators must independently agree. The threshold value is a deployment parameter; production deployments SHOULD select a threshold of at least ceil(2n/3) for Byzantine fault tolerance, where n is the size of the active Validator set.¶
2. Slashing. A Validator proven to have voted for a fraudulent batch loses the validator role and has the off-chain evidence hash recorded on-chain. A Validator that has been slashed for a prior epoch retains the vote it cast before the slash: historical votes are durable in order to preserve the audit trail.¶

The Validator role is distinct from the Attester (the on-device measurer and signer) and from the Verifier (the relying-party-side software). The Attester proves a measurement was taken on certified hardware; the Validator proves a quorum of independent parties agree the measurement appeared in a legitimate batch; the Verifier checks both layers when consuming an attestation.¶

4.1. Claim Set

The evidence payload is a CBOR map using the integer labels listed in Table 1. These labels are local to this profile and are scoped to the payload map only; they are independent of the COSE header labels used in the enveloping structure (Section 4.2).¶

The "prev" value of token n is the SHA-256 digest of the deterministically encoded evidence payload of token n-1, that is, of the content of the "payload" byte string of its COSE_Sign1 structure (Section 5.1). Hashing the payload rather than the complete token makes the hash chain independent of the signature value and of the unprotected header. The "cfg" value is a SHA-256 digest over a deployment-defined serialization of the configuration it covers; that serialization is identified through the Reference Values against which "cfg" is compared (Section 7.2). Both "fwv" and "cfg" are reported by the host and are subject to the limitation described in Section 10.1.¶

The evidence payload carries no signature claim and no algorithm claim. The signature, the signature algorithm, and the key identifier are carried by the enveloping COSE_Sign1 structure as described in Section 4.2 and Section 5.1.¶

4.2. Algorithm and Key Identification

Algorithm agility in this protocol is provided exclusively by the COSE protected header of the enveloping COSE_Sign1 structure. Specifically:¶

• The "alg" header parameter (COSE header label 1) identifies the signature algorithm. It MUST be present in the protected header. For this version of the protocol its value MUST be -9 (ESP256), as registered in [RFC9864]. The compatibility rule for the value -7 is given in Section 5.¶
• The "kid" header parameter (COSE header label 4) identifies the endorsed device key used to produce the signature. It SHOULD be present in the protected header. Where it is absent, a Verifier MUST resolve the key from the "iss" claim through the registry of Section 7.1.¶

An implementation MUST NOT convey the signature algorithm as a claim inside the evidence payload. A Verifier that encounters an algorithm indication inside the evidence payload MUST reject the token, because such an indication would create a second and possibly disagreeing source of truth for algorithm selection.¶

The unprotected header of an attestation token MUST be an empty map. Attesters and aggregators MUST NOT add unprotected header parameters, and a Verifier MUST NOT use the content of the unprotected header when identifying a measurement (Section 9.5). Implementations MAY include the "typ" header parameter [RFC9596] in the protected header; a value for it is left for a future revision.¶

4.3. CDDL Definition

The following CDDL [RFC8610] defines the attestation token. It is normative for the structures it covers.¶

; A Noethrion attestation token is a tagged COSE_Sign1 structure.
Noethrion-Attestation = #6.18(Noethrion-Sign1)

Noethrion-Sign1 = [
  protected   : bstr .cbor Noethrion-Protected-Header,
  unprotected : Noethrion-Unprotected-Header,
  payload     : bstr .cbor Noethrion-Claims,
  signature   : bstr
]

Noethrion-Protected-Header = {
  1 => -9,                ; alg: ESP256 (see Section 5 for -7)
  ? 4 => bstr,            ; kid; endorsed device key identifier
  * cose-label => any
}

Noethrion-Unprotected-Header = {}   ; MUST be empty

Noethrion-Claims = {
  1 => bstr .size 9,      ; iss:  secure element serial number
  2 => uint,              ; iat:  issued-at, UTC seconds
  3 => uint,              ; wh:   energy delta, watt-hours
  4 => uint .ge 1,        ; seq:  per-device monotonic counter
  5 => sha256-digest / null,
                          ; prev: SHA-256 of previous payload;
                          ;       null if and only if seq == 1
  ? 6 => tstr,            ; fwv:  firmware version (host-reported)
  ? 7 => tstr,            ; mdl:  device model identifier
  ? 8 => sha256-digest,   ; cfg:  config digest (host-reported)
}

sha256-digest = bstr .size 32

cose-label = int / tstr

The Merkle aggregation layer of Section 6 and the claim-record encoding of Section 6.3.1 are not yet expressed in CDDL. [TBD: full CDDL covering the batch, inclusion-proof, and claim-record structures in a future revision]¶

4.4. Mapping to EAT

The claim set above is intentionally compatible with the Entity Attestation Token (EAT) format defined in [RFC9711]. EAT is itself carried in COSE, so the envelope chosen in Section 5.1 is the same one an EAT profile would use. The claim labels of Table 1 are, however, local to this profile, and the payload is not itself an EAT claims set.¶

Table 2 lists, for information, the EAT or CWT [RFC8392] claims that correspond most closely to each claim of this profile. It corrects the statement in -00 that "iss", "iat", and "seq" can be mapped directly to CWT-registered claims: only "iat" has a direct equivalent. The table does not change the wire format defined in this document; a formal EAT profile for energy attestation, including a profile identifier for the "eat_profile" claim (key 265), is left for a future revision.¶

5.1. Signature Envelope

Attestation tokens MUST be signed as a COSE_Sign1 structure as defined in [RFC9052], Section 4.2, tagged with CBOR tag 18. COSE_Sign1 is chosen over a bare signature field for three reasons:¶

1. It is the envelope used by the Entity Attestation Token [RFC9711] and by the wider RATS ecosystem [RFC9334], so that evidence produced under this specification can be consumed by existing COSE and EAT tooling without a bespoke parser.¶
2. It provides integrity protection over the algorithm and key identifiers themselves, through the protected header, which a bare signature over a claims map does not.¶
3. It gives a single, already-specified path for algorithm rotation (Section 5.3).¶

The signature is computed over the Sig_structure defined in [RFC9052], Section 4.4, with:¶

• "context" set to the text string "Signature1";¶
• "body_protected" set to the serialized protected header;¶
• "external_aad" set to a zero-length byte string in this version;¶
• "payload" set to the deterministically encoded evidence payload of Section 4.1.¶

Implementations MUST NOT emit an attestation token as a bare claims map with an adjacent signature field. Pre-standard implementations of this protocol, including the genesis deployment of the reference implementation, used such a bare encoding. That encoding is historical, is not conformant with this document, and MUST NOT be used for new deployments. Verifiers MAY retain support for it solely in order to re-verify pre-standard historical records, and then only for records already contained in batches finalized before a fixed, deployment-defined cutoff. Because the secure element signs whatever digest the host presents, a bare record that is not so committed provides no assurance that it was produced before the cutoff.¶

5.2. Rationale for P-256

P-256 is selected because:¶

1. It is the curve natively supported by widely available secure elements suitable for low-cost meter integration, including parts certified to Common Criteria EAL5+.¶
2. It is broadly understood, has mature implementations, and is acceptable to relying parties whose internal cryptographic policies typically permit NIST curves.¶
3. Performance on constrained microcontrollers is sufficient for the protocol's per-minute signing cadence.¶

5.3. Post-Quantum Migration

It is acknowledged that P-256 is not post-quantum secure. A migration path to a post-quantum signature scheme, anticipated to be ML-DSA as standardized in [FIPS204], is part of the protocol's long-term plan. No new format machinery is required for that migration: the "alg" and "kid" parameters of the COSE protected header (Section 4.2) are the algorithm and key rotation mechanism, and a future revision need only permit an additional "alg" value and specify the transition policy. Historical attestations remain verifiable because each token names, under integrity protection, the algorithm with which it was signed.¶

A future revision of this document SHALL specify the migration procedure, including dual-signing transitions and the policy under which historical P-256 attestations remain verifiable.¶

6.1. Off-Chain Aggregation

Attestation tokens are aggregated off-chain into Merkle trees. Each tree contains up to 2^16 (65,536) leaves, where each leaf is the SHA-256 hash of the complete deterministically encoded, tagged COSE_Sign1 attestation token of Section 4.¶

Interior nodes are computed with a commutative sorted-pair construction:¶

parent = keccak256(min(a, b) || max(a, b))

where a and b are the two 32-byte child hashes, min and max denote lexicographic byte-wise ordering, and keccak256 is the original Keccak-256 function [KECCAK] with its original padding, which is not the SHA3-256 function standardized in FIPS 202. Sorting each pair before hashing makes the construction order-independent: an inclusion proof carries only the sibling hashes, with no left/right position flags. This is the construction implemented by the widely used Merkle proof library employed by the on-chain reference contract and by the reference off-chain Verifier tooling. Off-chain builders MUST use this pair hash for any tree whose root is committed on-chain.¶

Note on leaf domain separation: this construction deliberately omits the per-level domain-separation prefixes (0x00 for leaves, 0x01 for interior nodes) defined by [RFC9162]. The second-preimage class those prefixes guard against, namely reinterpreting an interior node as a leaf or vice versa, is structurally closed here by preimage length: an interior-node preimage is exactly 64 bytes (two concatenated 32-byte hashes), whereas leaf preimages are never 64 bytes. The on-chain claim-record leaf (Section 6.3.1) hashes a 160-byte encoded payload, and the attestation-evidence leaf hashes a tagged COSE_Sign1 token, which is substantially longer than 64 bytes for any token carrying the required claims of Section 4.1 together with a 64-byte ECDSA P-256 signature. The attestation-evidence leaf additionally uses a different hash function, SHA-256, from the keccak256 node hash. [RFC9162] informed the design of this layer and is listed as an informative reference.¶

A batch is identified by a monotonically increasing epoch number. The aggregator MAY be operated by the device owner, by a service provider, or by the reference implementation; the choice does not affect verifiability.¶

6.2. On-Chain Commitment

For each batch, the Merkle root is committed to a public EVM-compatible Layer 2 settlement network through a reference smart contract. Note that the reference contract is named "Attester" for historical reasons unrelated to the RATS Attester role of Section 3.1; the two are distinct. The on-chain commitment record SHALL include, at minimum:¶

• the epoch number;¶
• the Merkle root (32 bytes);¶
• the total watt-hour sum claimed in the batch, for cross-check against grid-level dispatch records;¶
• the proposing validator's address, and, through separate vote events, the addresses of all validators who voted to reach quorum;¶
• the block timestamp at submission;¶
• the quorum threshold value active at the moment of submission. Snapshotting this at submission, rather than reading live storage at finalization, ensures that a subsequent administrative change to the global threshold cannot retroactively pass or block this specific batch;¶
• the challenge-window value active at the moment of submission. Snapshotting prevents retroactive shrinking, which would let an administrator finalize batches early, and retroactive extension, which would freeze finalization of legitimately voted batches.¶

The two snapshot fields close the symmetric retroactive-shift class of administrative abuses.¶

A challenge window, configurable and defaulting to one hour, follows submission. In the current reference contract the fraud-proof path during this window is off-chain: any party MAY report evidence of a fraudulent batch to the contract operators and validators, who can respond through the on-chain pause mechanism, blocking finalization, and administratively triggered slashing (Section 10.4). A dedicated on-chain challenge entry point, allowing any party to publish a fraud proof directly on-chain, is deferred to a future protocol extension, together with fraud-proof-verified slashing. After the challenge window expires without the batch being rejected, the batch is finalized; finalization is irreversible.¶

The block timestamp recorded at submission is the Anchor Time of every token in the batch. It is set by the settlement layer and not by the Attester or its host, and it is the reference time for the revocation and timestamp-plausibility checks of Section 7.3, Section 7.4, and Section 9.5. A Verifier that appraises a token not yet contained in a committed batch MUST use its own time of receipt of the token in place of the Anchor Time.¶

6.3. Verification Path

A Verifier resolves a single attestation as follows:¶

1. Receive the candidate attestation token and a Merkle inclusion proof, consisting of the sibling hashes along the tree path.¶
2. Compute the SHA-256 leaf hash over the deterministically encoded, tagged COSE_Sign1 token.¶
3. Apply the inclusion proof to derive the candidate Merkle root.¶
4. Look up the on-chain commitment for the corresponding epoch.¶
5. Confirm that the candidate root equals the committed root.¶
6. Confirm that the batch is finalized, that is, that the challenge window has elapsed without a successful challenge.¶
7. Validate the COSE_Sign1 signature (Section 5.1) against the device Attester's endorsed public key: the secure-element-bound key of Section 3.1, and not the on-chain contract of Section 6.2.¶
8. Confirm, against the Anchor Time of the batch (Section 6.2), that neither the device key nor its Endorser is revoked (Section 7.3, Section 7.4) and that the token's "iat" is plausible (Section 9.5).¶

All eight steps MUST succeed for the attestation to be accepted.¶

6.4. Relationship to Transparency Services

The commitment layer of this section registers batches of signed statements in a verifiable data structure and lets a Verifier check inclusion. This is the function standardized by the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture [RFC9943], with inclusion proofs conveyed as COSE Receipts [RFC9942]. A SCITT Transparency Service is a possible IETF-aligned transport and transparency layer for attestation tokens, either alongside or instead of the settlement layer described here. This version does not specify such use; a future revision is expected to evaluate it. The token format of Section 4 does not depend on the commitment layer.¶

7.1. Public Key Registry

Endorsed device public keys are recorded in a registry. The registry MAY be:¶

• on-chain, as a smart-contract mapping from device serial number to public key and endorsement metadata, with role-based mutation rights restricted to Endorsers. This is the reference deployment;¶
• off-chain, distributed as signed JSON files at well-known URLs maintained by Endorsers;¶
• hybrid, with on-chain anchors and off-chain bulk distribution.¶

The choice is operational and does not affect the verification semantics: a Verifier MUST be able to obtain a device's endorsed public key, traceable to an Endorser whose own key is verifiable. The content of a registry entry MAY be a CoRIM as described in Section 7.2; in the hybrid case, an on-chain anchor MAY record the digest of a signed CoRIM distributed off-chain.¶

7.2. Endorsements and Reference Values Using CoRIM

To allow general-purpose RATS Verifiers to consume them, Endorsers SHOULD be able to express device-key endorsements and Reference Values as a signed Concise Reference Integrity Manifest (CoRIM) [I-D.ietf-rats-corim]. The registry forms of Section 7.1 remain permitted; this section describes how their content maps onto CoRIM, and does not introduce new information. Terminology for Endorsements follows [I-D.ietf-rats-endorsements].¶

• Device public key. The endorsed device key is conveyed in an Attest Key Triple ([I-D.ietf-rats-corim], Section 5.1.10). The environment identifies the device class (for example vendor and model) and the instance, using the secure element serial number carried in the "iss" claim; the key list contains the device's P-256 public key. The "kid" header parameter of Section 4.2, when present, SHOULD allow the Verifier to locate this key.¶
• Reference Values. Expected firmware version ("fwv"), model ("mdl"), and configuration digest ("cfg") are conveyed in Reference Values Triples ([I-D.ietf-rats-corim], Section 5.1.5), against which the Verifier compares the corresponding claims.¶
• Endorsed Values. Properties that the Attester cannot itself report, such as the certification status of the secure element and the class of protection applied to the measurer-to-signer interface (Section 10.2), are conveyed in Endorsed Values Triples ([I-D.ietf-rats-corim], Section 5.1.6).¶

A CoRIM is signed by the Endorser. The requirement of Section 3.4 that the Endorser's own key be verifiable applies to the CoRIM signing key. The revocation semantics of Section 7.3 and Section 7.4 apply regardless of the encoding used for the endorsement; this document does not depend on any CoRIM-specific revocation mechanism.¶

7.3. Endorser Revocation

An Endorser MAY revoke an endorsement, for example on discovery of a compromised provisioning batch. Revocations SHALL be timestamped with an effective time, which MAY be earlier than the time of issuance when the Endorser knows when a compromise began. A Verifier MUST evaluate revocation against the Anchor Time of the batch containing the attestation (Section 6.2), and not against the attestation's "iat", because "iat" is set by the Attester's host and can be back-dated by an adversary that controls the host or holds an extracted key. An attestation whose Anchor Time is at or after the effective time of a revocation of its Endorser MUST be rejected.¶

7.4. Device-Level Revocation

A device's endorsement MAY be revoked individually, for example on suspicion of physical tampering reported through the protocol's challenge mechanism, or on detection of equivocation (Section 9.5). Attestations from a revoked device whose Anchor Time (Section 6.2) is at or after the effective time of the revocation MUST be rejected, whatever their "iat" value.¶

8.1. Appraisal Records

The EAR contains one EAR-appraisal entry in its "submods" claim for each appraised attestation token, because the "ear_attester_claims" of an EAR-appraisal carry the claims of a single appraisal [I-D.ietf-rats-ear]. The label of that entry SHOULD be the lowercase hexadecimal encoding of the token's "iss" claim, followed by a hyphen and the decimal value of its "seq" claim, so that results for the same measurement (Section 9.5) are labelled consistently across Verifiers. As required by [I-D.ietf-rats-ear], the top-level "ear_status" of an EAR reporting on several tokens is no higher than the worst "ear_status" among its entries.¶

The "ear_status" of an appraisal entry is a trustworthiness tier of [I-D.ietf-rats-ar4si]. As required by [I-D.ietf-rats-ear], it MUST NOT be a tier of higher trust than the tier of the worst claim in the trustworthiness vector of that entry. Within that limit, it is assigned as follows:¶

• "affirming" only if all steps of the verification path of Section 6.3 succeed, including finalization, and no claim of the trustworthiness vector is in the Warning or Contraindicated tier. Because "sourced-data" is in the Warning tier unless the measurer has itself been appraised (Section 8.2), a deployment whose measurer-to-signer interface is unauthenticated obtains at most "warning".¶
• No higher than "warning" if every step other than finalization succeeds but the batch is still within its challenge window. Such a result MUST NOT be treated by a Relying Party as evidence of finalized generation.¶
• "contraindicated" if the signature fails to validate, the Merkle inclusion proof does not match the committed root, the device or its Endorser is revoked as of the Anchor Time of the batch (Section 6.2), the "iat" plausibility check fails, or equivocation is detected (Section 9.5).¶

8.2. Trustworthiness Vector

The Verifier SHOULD include the trustworthiness vector of [I-D.ietf-rats-ar4si], populated as follows. Values are those defined in that document. Claims not listed are left unasserted; a value of 0 (no assertion) is equivalent to an unasserted claim.¶

instance-identity:

2 when the device key is endorsed and not revoked as of the Anchor Time; 96 when it is revoked. 97 only when no endorsement is found for a device that the Verifier expects to recognize, for example because its "iss" appears in an Endorser's provisioning records; otherwise the claim is unasserted. A token without an endorsed key cannot pass the verification path, and its "ear_status" is not "affirming".¶

hardware:

2 when an endorsement asserts that the key is held in a secure element meeting the Endorser's stated provisioning procedure (Section 3.4); otherwise unasserted (0).¶

executables and configuration:

The "fwv" and "cfg" claims are reported by the host and are not measured by the secure element (Section 10.1). A Verifier MUST NOT assign a value in the Affirming tier to these claims on the basis of "fwv" and "cfg" alone, unless an Endorsement asserts that those values are measured by a root of trust rather than reported by the host. Where they match Reference Values, the claims are otherwise left unasserted. Where they do not match, the Verifier assigns 33 to "executables" and 95 to "configuration".¶

sourced-data:

2 only when the readings are authenticated by the measurer (Section 10.2) and the measurer has itself been appraised as an Attester, for example as a separate EAR-appraisal of a composite Attester, with a result that meets the conditions of [I-D.ietf-rats-ar4si] for that value. An Endorsement stating that the measurer-to-signer interface is authenticated is not sufficient on its own. Otherwise 32, which denotes data from unattested sources. A Verifier MUST NOT assign an affirming value to this claim on the basis of the Attester's signature alone, because that signature does not cover the measurer-to-signer interface. Appraisal of the measurer is not further specified in this version.¶

The value 99 (cryptographic validation of the Evidence has failed) applies to any claim affected by a failed signature or inclusion-proof check.¶

8.3. Attested Quantities

An EAR describes an appraisal; it does not by itself convey the quantity of energy appraised. To let a Relying Party act on the result without re-parsing the token, the Verifier SHOULD include in "ear_attester_claims" the "iss", "iat", "seq", and "wh" claims of the appraised token, and in "ear_verifier_claims" the epoch, the Anchor Time, the leaf hash of the token, and the Measurement Interval derived as described in Section 9. The Verifier MAY include the complete Attestation Token in "ear_raw_evidence", wrapped as a Conceptual Message Wrapper [RFC9999]; the privacy considerations of Section 11 apply to that choice.¶

An "affirming" result states that the checks of this document succeeded. It does not extend the assurance of the protocol beyond the limits described in Section 10.2; a Relying Party SHOULD consult the "sourced-data" claim before relying on a result for regulatory or financial settlement.¶

9.1. Measurement Intervals

Each token reports in "wh" the energy measured since the previous token from the same device. For a token with "seq" equal to n greater than 1, the Measurement Interval is the half-open interval from the "iat" of token n-1, exclusive, to the "iat" of token n, inclusive. A Verifier MUST derive a Measurement Interval only from a verified contiguous pair: token n-1 has passed the verification path of Section 6.3, the "prev" claim of token n matches the hash of the evidence payload of token n-1 (Section 4.1), and the "iat" of token n is strictly greater than the "iat" of token n-1. Attesters MUST emit strictly increasing "iat" values. A pair that satisfies the "prev" check but not the "iat" check is non-conformant: the Verifier MUST NOT derive an interval from it and MUST appraise token n as contraindicated. The "wh" of the first token ("seq" equal to 1) has no defined interval and MUST NOT be attributed to any interval.¶

A gap in the sequence, or a "prev" value that does not match, means that the energy for the affected period is not attested. In line with the fail-closed rule of Section 10.2, a Verifier or Relying Party MUST NOT fill such a gap by interpolation or by an unattested reading.¶

9.2. Alignment with Hour Boundaries

An Attester intended for hourly accounting SHOULD emit a token at each hour boundary in UTC, in addition to any finer reporting cadence, so that no Measurement Interval spans a boundary. For this purpose, hour h is the half-open interval from h*3600 seconds, exclusive, to (h+1)*3600 seconds, inclusive, in the time scale of the "iat" claim, matching the orientation of Measurement Intervals; a token emitted exactly at a boundary closes the hour that ends there. A Measurement Interval from t1, exclusive, to t2, inclusive, lies within hour h if h*3600 is less than or equal to t1 and t2 is less than or equal to (h+1)*3600. The hourly total of attested generation for a device is then the sum of "wh" over the tokens whose Measurement Interval lies within that hour.¶

When a Measurement Interval spans one or more hour boundaries, this document does not define how its energy is apportioned among the hours. A Relying Party that apportions such an interval does so under its own policy and SHOULD record the method used; a Verifier MUST NOT apportion silently.¶

9.3. Matching Consumption to Generation

Hourly matching compares, for each hour, attested generation with consumption attributed to a consumer. This document specifies only the generation side. The source of consumption data, the rules that decide which generation may be matched to which consumption (for example by grid region), and the allocation of a device's generation among several consumers are matters for the Relying Party or for the applicable certificate scheme, and are out of scope.¶

The same attested generation MUST NOT be counted toward more than one claim. Preventing such reuse is the responsibility of the claim layer (Section 6.3.1) and of any external scheme that consumes attestations; such systems MUST detect reuse using the measurement identifier of Section 9.5, and MUST NOT use the leaf hash for that purpose.¶

9.4. Time Integrity and Privacy

Attribution of energy to an hour depends on the "iat" claim and therefore on the integrity of the Attester's time source (Section 12). Deployments that need freshness bounds independent of the Attester's clock MAY use Epoch Markers [I-D.ietf-rats-epoch-markers]; such use is not specified in this version and would require an Evidence claim carrying the epoch identifier.¶

Timestamp rounding for privacy (Section 11.2) interacts with hourly accounting: a rounding granularity coarser than one hour prevents hourly attribution. Where rounding is applied to tokens used for hourly accounting, the granularity SHOULD divide one hour evenly, so that rounded boundary tokens remain on the hour boundary. Rounding MUST preserve strictly increasing "iat" values: an Attester that rounds "iat" emits at most one token per rounding bucket, merging the energy of the bucket into that token.¶

9.5. Measurement Identity and Equivocation

A measurement is identified by the pair ("iss", "seq") of the token that reports it. The leaf hash of Section 6.1 is not a stable identifier for this purpose: ECDSA signatures are randomized and malleable, so the same evidence payload can appear in several valid tokens with different leaf hashes, and the unprotected header is not covered by the signature. Accordingly:¶

• Two tokens with the same ("iss", "seq") and identical evidence payloads report the same measurement. Their energy MUST be counted at most once, whichever batches, intervals, or claims they appear in.¶
• Two tokens with the same ("iss", "seq") and different evidence payloads constitute equivocation by the device or its host. A Verifier that observes equivocation MUST appraise both tokens as contraindicated, MUST NOT attribute the energy of either to any interval, and SHOULD report the device for revocation (Section 7.4). Validators SHOULD check, before voting, that no ("iss", "seq") in a proposed batch appears with a different payload in that batch or in an earlier committed batch.¶
• The "iat" of a token MUST NOT exceed its Anchor Time (Section 6.2) by more than a deployment-defined maximum clock skew. A token that fails this check is appraised as contraindicated. Because the host controls the Attester's clock, this bound, not the Attester's time source, is the time check that a Verifier can enforce.¶

Equivocation can be detected only by a party that observes both tokens. Detection is therefore strongest at the commitment layer, where all batches are visible, and a Relying Party that relies on a single Verifier depends on that Verifier's view.¶

10.1. Compromised Host MCU

The host microcontroller adjacent to the secure element may be compromised. Because the signing key is generated on-chip and never leaves the secure element, a compromised host can lie about what to sign but cannot forge signatures under the device's public key.¶

The "fwv" and "cfg" claims do not mitigate this threat. They are written by the same host that is assumed to be compromised, and the secure element signs whatever digest it receives without measuring the host: it is not a root of trust for measurement. A compromised host can therefore report the expected firmware version and configuration digest. Unless those values are measured by the secure element or by another root of trust, comparing them with Reference Values detects misconfiguration of an honest host, not a tampered one (see also Section 8.2). Deployments SHOULD use host secure boot. Layered attestation of the host, in which each boot stage is measured before it runs, is left for a future revision.¶

10.2. Meter Substitution and Physical Tampering

The Attester is composed of a measurer and a signer (Section 3.1). Every cryptographic guarantee in this document applies to the signer: a valid attestation proves that a particular secure element signed a particular set of numbers. It does not, on its own, prove that those numbers came from the meter the Endorser expects, nor that they correspond to physical energy flow. The measurer-to-signer interface is consequently the weakest link in the chain of custody, and it is where the adversaries below operate.¶

Meter substitution. An adversary with physical access may replace the meter, or interpose on the measurer-to-signer interface, and present fabricated readings to the secure element. The secure element signs them faithfully and verification succeeds at every later stage: the signature is valid, the endorsement chain is intact, the hash chain is continuous, and the on-chain commitment is well formed. Where the measurer-to-signer interface is unauthenticated, as it is on a bare pulse output or an unauthenticated serial connection, no mechanism defined in this document detects this attack.¶

Substitution after verification. A measurer that is verified only once, at commissioning or at Attester power-on, provides no continuing guarantee: an adversary may satisfy the check with a genuine meter and substitute afterwards. Implementations MUST NOT treat a commissioning-time verification of the measurer as evidence about readings produced later.¶

Physical tampering of a genuine meter. The meter or its sealing may be tampered with in order to distort readings at the point of measurement. This protocol does not detect such tampering; the existing physical-seal and audit regime of revenue-grade metering, which predates this protocol, remains necessary. That regime is complementary to the mitigations below, not a substitute for them, because a seal constrains the meter itself and says nothing about what reaches the signer.¶

Secure-element substitution. This case is detected, because the device serial number changes and the new public key has no endorsement chain.¶

The following mitigations apply to the measurer-to-signer interface.¶

• Authenticated measurement. The Attester SHOULD be built on a meter whose metrology function authenticates each reading under a key held in the meter's own protected storage, and the secure element SHOULD verify that authentication before including a reading in the claim set.¶
• Continuous rather than one-time verification. Where the interface supports authentication, the Attester SHOULD verify it at every reporting interval rather than only at commissioning, so that no window exists in which a verified measurer can be exchanged for an unverified one without detection.¶
• Fail-closed behaviour. If the measurer cannot be authenticated, becomes unavailable, or returns readings inconsistent with the Attester's monotonic energy counter, the Attester MUST NOT emit an attestation covering the affected interval. Emitting an attestation over unauthenticated readings, or falling back to an unauthenticated interface, defeats the purpose of signing them. A Relying Party MUST treat the absence of an attestation as the absence of attested generation, and MUST NOT substitute an unattested reading in its place.¶

Residual risk. Deployments whose measurer-to-signer interface is unauthenticated retain the full meter-substitution risk described above. For those deployments the assurance offered by this protocol degrades from "this quantity of energy was generated" to "this secure element reported this quantity", and the binding to physical generation rests entirely on out-of-band procedures. Deployments supporting regulatory or financial settlement SHOULD use an authenticated measurement interface for this reason. So that a Relying Party can apply policy to the class of measurer-to-signer protection rather than assuming it, that class is asserted by the Endorser (Section 7.2) and is reflected in the "sourced-data" claim of the Attestation Result (Section 8.2), which is affirming only when the measurer has itself been appraised. A claim by which the Attester itself reports that class is left for a future revision.¶

10.3. Secure-Element Key Extraction

Extraction of the signing key from a Common Criteria EAL5+ secure element is currently considered infeasible against the design assumptions of state-of-the-art parts. If such an extraction becomes feasible, the affected device family's endorsements SHALL be revoked. Back-dating with an extracted key is limited because revocation and "iat" plausibility are evaluated against the Anchor Time of the batch, which the key holder does not control (Section 7.4, Section 9.5), and because historical attestations are already anchored on-chain.¶

10.4. Validator Collusion

A validator could withhold attestations or propose a batch with a Merkle root that does not correspond to the claimed leaves. Three mechanisms address this in combination:¶

1. m-of-n threshold quorum. Finalization requires a threshold number of distinct validator votes through the propose, vote, and finalize sequence. A single party cannot cause a batch to be finalized. The threshold MUST be selected such that coalition cost exceeds expected fraud value; analogous systems typically use ceil(2n/3) for Byzantine fault tolerance.¶
2. Challenge window. Independently of the threshold mechanism, between submission and earliest finalization any party MAY report evidence of fraud. In the current reference implementation this path is off-chain: evidence is reported to operators and validators, who block finalization through the pause mechanism and apply slashing. An on-chain challenge entry point is deferred to a future revision (Section 6.2). A batch successfully challenged within the window is never finalized.¶
3. Slashing. Validators proven to have voted for fraudulent batches MAY be slashed: the validator role is revoked and the off-chain evidence hash is recorded on-chain. The current reference contract implements administratively triggered slashing; on-chain fraud-proof verification feeding slashing automatically is deferred to a future revision.¶

A coalition of threshold-many validators colluding within the challenge window can still finalize a fraudulent batch. This is the residual risk; it shrinks but does not disappear with the threshold mechanism. Production deployments SHOULD treat the challenge-window fraud-proof path as load-bearing.¶

10.5. Replay Attacks

Replay of an old attestation as a new one gains an adversary nothing, because a measurement is identified by ("iss", "seq") and is counted at most once (Section 9.5). A token that reuses an existing ("iss", "seq") with a different payload is equivocation and is handled as specified in Section 9.5; the "prev" hash chain links each token to its predecessor (Section 9.1). A Verifier MUST NOT reject a token solely because its "seq" is lower than a value it has observed before, since historical and out-of-order verification of single tokens is a supported use.¶

10.6. Side-Channel Observation

Side-channel attacks against the secure element, including power analysis, electromagnetic analysis, and fault injection, are mitigated by the Common Criteria certification regime governing the part. Operators SHOULD follow vendor guidance on physical deployment in order to reduce exposure.¶

11.1. Inferences from Attestations

A continuous record of per-device generation timestamps can be correlated with consumption patterns in order to infer the occupancy and behavior of a household. Aggregation and timestamp rounding mitigate but do not eliminate this risk.¶

11.2. Mitigations

• Timestamp rounding. Producers MAY round "iat" to a coarser resolution, for example ten-minute buckets, at the cost of reduced verification granularity (see also Section 9.4).¶
• Batch padding. Aggregators SHOULD pad batches with dummy leaves so that a small-scale producer's contribution count is not distinguishable.¶
• Optional zero-knowledge extensions. A future revision will specify an optional zero-knowledge-friendly attestation variant in which the per-device identifier is replaced by a commitment, with selective-disclosure proofs available to authorized auditors.¶

11.3. Right to Opt Out

Participation in the protocol is, by design, voluntary. Operators are not required to publish attestations; the protocol's value derives from voluntary adoption by parties that wish to be cryptographically credible.¶