Summary

  • draft-ietf-anima-rfc8366bis-36 calls last-renewal-date an informative projection that Pledges do not process. It records a MASA's promise horizon; it does not extend expires-on or prove a replacement exists.
  • A real renewal begins later: a Registrar signs a fresh request carrying the old Voucher, and the MASA evaluates current Domain-key control, certificate status and policy before it can issue a new artifact.

A date inside a signed object feels unusually authoritative. It survived serialization. It sits under a manufacturer's signature. It can be archived beside the device record. When that date is named last-renewal-date, an asset system may be tempted to display it as “renewal guaranteed until”.

The YANG definition says something narrower. The field is the date the Manufacturer Authorized Signing Authority projects to be the last date on which it will renew a Voucher. It is “merely informative”. Pledges do not process it. It can appear only when expires-on also appears, and it does not replace or extend that expiry.

The distinction is not semantic housekeeping. It is the distance between a promise and an executed control path.

Revision 36 names the gates after the promise

Datatracker records revision 36, dated 9 September 2026, as an active ANIMA Working Group Internet-Draft. It is intended for Proposed Standard and is in IESG Evaluation::Revised I-D Needed. The record still shows two DISCUSSes, two additional YES or NO OBJECTION positions needed and an IANA review that must be revisited after a version change.

The draft would obsolete RFC 8366 and update RFC 8995 if approved. That condition belongs in every operational reading. Revision 36 is current standards work, not the replacement RFC and not a production deployment report.

Neither the renewal idea nor last-renewal-date is new. RFC 8366 already recommended short-lived, non-revocable Vouchers coupled to lightweight reissuance. Revision 35 carried the same basic language. What revision 36 adds is a more useful account of the later decision.

The MASA does not simply copy the old date into a new envelope. It verifies a freshly signed Registrar Voucher Request. It checks that the requesting Registrar still has access to the Domain's private key. It checks revocation status for the Domain identity certificate. It applies policy that may have changed since the earlier issuance—perhaps an Owner has blocked further renewal, or a support contract has expired. The Registrar includes the old Voucher in prior-signed-voucher-request and signs the new request.

Those clauses turn a vague “lightweight renewal” into a visible control surface. They also make it impossible to treat the old promise as the result of those checks.

The field is not an expiry and not an availability monitor

There are at least three times in the design. created-on describes creation. expires-on bounds use when the Pledge can evaluate time. last-renewal-date describes the MASA's projected outer horizon for offering renewal.

Only one of those is the current Voucher's expiry. The promise field cannot make an expired Voucher current. It does not tell a clockless Pledge what time it is. It does not reserve capacity at the MASA, prove the DNS and routing path works, prove the endpoint accepts the artifact profile, or establish that the organisation operating the MASA will still exist under the same policy.

The draft itself anticipates policy movement. Its YANG description says later circumstances can alter validity periods and gives support-contract termination or extension as an example. A signed projection is therefore evidence of what the issuer projected at one issuance event. It is not a cryptographic prohibition against future policy change.

This is the correct kind of honesty for a long-lived device system. The mistake would be added later, when inventory software promotes the projection into a service-level guarantee that the protocol never made.

A renewal request is still not a renewal

The fresh RVR creates a second boundary. Its signature can authenticate the Registrar's request within the applicable certificate and key context. Including the old Voucher identifies the artifact whose relationship is being continued. Proof of the Domain private key can show that the requester retains the relevant control material.

None of those facts is the replacement Voucher.

The MASA may reject the request after certificate or policy checks. A request can time out before a decision. A response can be issued and lost. A Registrar can receive the new Voucher while the intended Pledge never validates it. The Pledge can accept the Voucher's signer and Domain binding while a later enrollment or configuration step fails. The device can finish onboarding while the service outcome leadership expected still does not occur.

A useful evidence model therefore preserves the sequence:

  1. Promise: exact old Voucher, signer chain, expires-on, last-renewal-date, serial/issuer binding and pinned Domain anchor.
  2. Readiness: tested MASA route, supported signing profile and a renewal exercise early enough to leave recovery time.
  3. Request: exact fresh RVR, Registrar signature, old-Voucher inclusion, request time and Domain-key proof.
  4. Eligibility: certificate status and the precise policy version evaluated.
  5. Issuance: exact replacement Voucher bytes, response time, signer and new validity interval.
  6. Acceptance: Pledge validation of freshness, identity binding and the Registrar's matching trust anchor.
  7. Completion: onboarding, enrollment and configuration receipts.
  8. Outcome: the intended device operates in the intended Domain and performs the intended action.

Collapsing the rows makes a dashboard simpler and a failure investigation much harder.

The non-revocable design makes rehearsal more important

The renewal model answers a real complexity problem. A long-lived assertion plus OCSP or CRL processing creates more protocols and more code paths. A Pledge might be unable to reach an OCSP responder. The draft instead recommends short-lived Vouchers renewed through the same artifact path. It says “short-lived” is defined by each onboarding mechanism and still permits long-lived Vouchers, although it defines no Voucher revocation method.

That trade moves operational weight onto timely reissuance. If the old Voucher cannot be revoked directly, short validity limits exposure only when clocks are sound and replacement remains obtainable. The farther a fleet is from its renewal deadline, the more time an operator has to repair routing, certificate, policy or ownership-record failures. A test performed after expiry proves mainly that the recovery window was missed.

An intermediate CA in the Voucher signing chain can still be revoked. That is a certificate-chain effect, not a hidden Voucher revocation service. Operators should record which layer failed rather than report all failures as “Voucher renewal”.

Freshness has a separate clock boundary

A nonceless Voucher can be checked for freshness only by comparing expires-on with the Pledge's internal clock. The draft warns that a clockless device cannot simply trust NTP because an attacker may control the time stream. Such a Pledge needs a nonce and a fresh ephemeral Voucher.

A nonceless Voucher may also be reused any number of times during its validity period. That can help a Domain owner repeat onboarding; it also lets anyone who acquires the Voucher attempt repeated onboarding against the named Pledge. The pinned Domain still constrains where the device should accept onboarding.

last-renewal-date changes none of this. It adds neither freshness nor single use. It cannot compensate for a bad clock, and it cannot prove the Registrar currently facing the Pledge is the one named by the pinned trust anchor.

Pinning is an authority boundary, not the business outcome

The Voucher's core job is to convey a trust anchor. That anchor lets the Pledge authenticate subsequent interactions with the Domain. The draft requires the Pledge to verify that the indicated anchor matches the Registrar with which it is communicating.

This is strong and bounded evidence. It helps prevent an attacker from using a Voucher for one Domain to onboard the Pledge into another. It does not prove that the intended Registrar is healthy, that later enrollment succeeds, that configuration is correct, or that the device produces the expected service result. RFC 8995 supplies the wider BRSKI workflow; the Voucher is one artifact inside it.

Leadership should resist turning “manufacturer-signed” into an all-purpose status light. Signature validity, serial/IDevID issuer binding, freshness, pinned-Domain match, renewal eligibility, replacement issuance, Pledge acceptance and operational outcome answer different questions.

A promise should trigger a test, not close a ticket

Heng Lu's Minimum Initial Specification and Running-Code Primacy provide a practical lens. A specification can define the common artifact and local checks. Future behavior becomes real for an operator when implementation, validation and use make it observable.

Applied here, last-renewal-date is coordination metadata. It helps plan the interval in which a MASA projects that it will consider renewal. The running-code receipt is a completed exercise: a fresh request traverses the intended path, current policy is evaluated, a replacement is issued, the Pledge accepts it and the wider onboarding outcome is verified.

The right dashboard wording is therefore bounded. “Issuer projected renewal through date X” can be true. “Last successful renewal test: date Y; replacement expires date Z; next test due date Q” can be true. “Renewal guaranteed” is not established by the field.

The draft promises a smaller operational model than a separate revocation system. It does not promise an operation without evidence.

Sources