Summary

  • Revision 36 of draft-ietf-anima-rfc8366bis became available on 9 September 2026. It remains an Internet-Draft in IESG Evaluation, not an RFC or approved Proposed Standard.
  • New text says voucher renewal confirms that the earlier relationship still holds. The MASA verifies a fresh Registrar Voucher Request, checks the Domain certificate's revocation status and applies changed policy, including a stop-renewal instruction or an expired support contract.
  • The renewed voucher is an authoritative signed outcome. It does not carry a common record of which certificate-status observation, policy version or exception produced that outcome; the sources do not show what deployed MASAs log privately.
  • A separate, compact renewal-decision receipt could preserve those inputs and results without putting commercial detail into the voucher or transferring authority away from the MASA and Domain owner. This is Daniel Kade's proposal, not IETF text.

The revision changes the meaning of “lightweight”

Revision 36 appeared on 9 September, a month after revision 35. The Datatracker history records the upload and a move from Revised I-D Needed to AD Followup. The current document remains in IESG Evaluation and is intended for the Standards Track. If approved, it would obsolete RFC 8366 and update RFC 8995. The conditional matters: a revised draft has not already changed either RFC.

The official comparison adds a much more precise account of renewal. Initial voucher issuance may involve heavyweight questions: is the requester who it claims to be, and does the pledge actually belong to it? Renewal does not rerun every initial check. It confirms that the relationship established earlier still holds.

That is why “lightweight” should not be read as “administrative”. The draft says the Manufacturer Authorized Signing Authority, or MASA, always verifies the newly signed Registrar Voucher Request. That verifies that the requesting Registrar still has access to the Domain's private key. The MASA also checks the Domain identity certificate's revocation status and applies policy that changed after the previous voucher. The examples are consequential: a Domain owner may have asked the MASA to block further renewals, or a support contract may have expired.

The work can be fully automated in most cases precisely because the decision surface has been narrowed. Automation does not remove the decision. It makes a service evaluate a compact set of facts at speed.

A fresh signature proves one input, not the whole decision

The Registrar creates a fresh Registrar Voucher Request and includes the old voucher in prior-signed-voucher-request. Its new signature is strong evidence of current access to the Domain key. It is not evidence that the certificate was unrevoked at a particular observation time, that the owner's stop list was consulted, or that a contract database returned an eligible state.

The MASA then issues a new signed voucher. That artifact binds the pledge to the permitted Domain and carries the fields that the pledge needs to validate onboarding. It is deliberately an authorisation artifact, not a transcript of every business and security system consulted by the issuer.

This division is sensible. A constrained pledge should not have to parse a support-contract decision, an OCSP response or a private policy document. Nor should commercial terms be copied into an artifact that can pass through Registrars and other intermediaries. Revision 36 separately warns that manufacturer-proprietary content must not contain data requiring confidentiality because vouchers may be logged or stored along the path.

But minimal wire data creates a second question for the organisation operating the MASA: what can it prove later? The new voucher proves that the service said yes. If the certificate-status source was stale, an owner block arrived milliseconds later, or a policy deployment was rolled back, the voucher alone cannot reconstruct which state the service evaluated. A local log may answer that question. The draft and public record do not establish that every implementation keeps the same fields, retention period or identifiers.

The gap is therefore interoperability of evidence, not an allegation that MASAs lack logs.

One pledge per voucher is already a governance choice

Revision 36 also explains why the format supports one serial number per voucher. An earlier design allowed one artifact to cover many pledges using regular-expression ranges. That made a later stop decision too coarse: blocking renewal for the group would be excessive when ownership of only one device had changed.

The single-pledge rule localises the consequence. It lets the issuer refuse one renewal without withdrawing permission from unrelated devices. The design does not prove that a serial number is globally unique, which is why the issuer identifier remains relevant. It does show that the document's unit of authorisation was shaped by the unit at which control might need to end.

That same granularity belongs in the evidence. A fleet-wide dashboard saying “renewals healthy” cannot explain which pledge, previous voucher, Domain identity and policy state produced a contested artifact. Conversely, a receipt need not expose a device's physical location or the text of its service contract. It needs stable references and result classes, not a data dump.

Time is a separate authority boundary

The draft recommends short-lived, non-revocable vouchers and renewal rather than a separate voucher-revocation object. The exact meaning of short-lived belongs to each onboarding mechanism. A voucher can still be affected by revocation in its certificate chain, but the voucher itself has no independent revocation mechanism.

Revision 36 sharpens the clock risk. A pledge processing an expiration-bearing, nonceless voucher needs an accurate internal clock and protection against tampering. It cannot simply trust Network Time Protocol during hostile onboarding because an attacker may control the NTP stream. Without trustworthy time, the expiration field offers little protection. A nonce can instead obtain a fresh, ephemeral voucher.

This clock problem should remain separate from the renewal-decision record. The MASA's evidence says why it issued a new artifact at a given moment. The pledge's evidence says whether it could establish freshness and match the pinned Domain when it consumed that artifact. Combining the two into one “valid” flag would hide which actor performed which check.

A minimal renewal-decision receipt

The smallest useful receipt would sit beside the MASA's internal decision, not necessarily inside the voucher. It could record:

  1. the digest of the previous voucher and the fresh Registrar Voucher Request;
  2. the pledge serial and issuer scope, the pinned Domain identity and the MASA identity;
  3. the request and decision times;
  4. the Domain-key-possession check and result;
  5. the certificate-status method, responder or list reference, observation time, freshness and result;
  6. the renewal-policy identifier, version and result;
  7. a compact commercial-state class where contract status is actually used;
  8. any exception or manual override, with the accountable authority rather than private reasoning;
  9. the final decision and the new validity interval; and
  10. the next review or stop-renewal trigger.

Hashes and controlled result codes can carry most of this without exposing certificates, contract prices, customer names or full policy text. Access to the detailed record can remain local. Two MASAs need not share the same commercial policy; they need a reproducible way to say which policy and evidence their own decision used.

This follows the minimum-initial-specification discipline in Heng Lu's essay. Standardise only what independent actors need to reproduce a boundary, leaving operational policy with those who bear the risk. The Policy Mirror supplies the complementary warning: automated execution should not make its governing rule invisible.

The receipt is my editorial proposal. Revision 36 does not require it, and neither the ANIMA working group nor the IESG has adopted it.

Evidence boundary

RFC 8995 defines the current BRSKI roles and audit context; RFC 8366 defines the current voucher artifact. RFC 5280 and RFC 6960 supply certificate-status foundations. The separate MASA considerations draft discusses operational models for the signing service but is also unfinished.

These sources show the protocol roles and revision delta. They do not show a deployed breach, an improper renewal, a stale status response, a contract dispute, a common implementation log or a deployment rate. The article therefore does not claim that automation is unsafe or that a particular vendor failed. Its bounded claim is that renewal has become visibly decision-bearing, while the common artifact remains an outcome rather than a portable explanation of the decision.

Sources