[Anima] Current status of draft-ietf-anima-rfc8366bis [Was Re: [iesg] Deb Cooley's Discuss on draft-ietf-anima-rfc8366bis-34: (with DISCUSS and COMMENT)]

[Mahesh Jethanandani <[e-mail]>]

Hi Authors:

Good progress on -35 — Ketan's and Roman's DISCUSSes are cleared; thank you for turning
that around. Eric's is also substantively addressed in -35 (see below), though it
still shows as open on the ballot. Deb's is the one where I don't see the fix landed yet.
I'd like to understand the plan for that, and get Eric's DISCUSS formally cleared, before
this document goes any further.

1. **Eric's Section 8.3 point (pinning consistency) — addressed in -35, but I'd like it
   confirmed.** GitHub PR #150 ("Éric Vyncke's AD Comments," merged 8/12, closing #144
   and #145) added the precedence text I'd been looking for: “In the event that more than
   one of pinned-domain-pubk-sha256, pinned-domain-pubk or pinned-domain-cert are present
   in a voucher, then the Pledge SHALL prioritize the proximity entry which it used in
   its voucher-request artifact, ignoring the others," with a fallback rule for
   nonce-less vouchers. The rewritten §12.4 (was §11.4) privacy considerations also looks
   like it answers his SHOULD-vs-MUST question with per-transport guidance (TLS/PRM/SZTP)
   instead of a blanket MUST. Two things I'd still want closed out, though:

   - The commented-out `choice pinning` / `choice nonceless` YANG constructs are
     untouched — Tommy's "why keep the dead code if it's not going to be used" comment
     is still unanswered. I would like to see all dead code removed. If you want, add text
     in the description explaining that it is a choice.

   - I want to make sure I'm reading the merged rule right, since it's a "pick the one
     you asked for and ignore the rest" answer rather than a cross-consistency check:
     the security argument seems to be that since the voucher is MASA-signed, an
     inconsistency between pinned-domain-cert/pubk/sha256 can only arise from a MASA
     bug (not a third party), so the Pledge doesn't need to detect or flag it — it just
     needs deterministic behavior, which "use the one matching your own request, ignore
     the others" provides. Can one of you confirm that's the intended reasoning? If so,
     I'd also like Eric to explicitly confirm -35 closes his DISCUSS, rather than
     inferring it from a ballot position that hasn't caught up yet.

2. **Deb's DISCUSS (PQ / crypto agility, no MTI) — the fix is still on the list, not in
   the draft.** Michael's 8/11 note proposing a "Planning for a transition to
   Quantum-Ready algorithms" section is the right shape of answer, but -35 (posted the
   next day) doesn't contain it — §8.1 only adds a forward pointer to
   draft-richardson-anima-quantum-safe-4ani. That pointer alone won't resolve Deb's
   DISCUSS; she and Roman were both asking for this document to say something concrete
   about migration/agility, not defer it entirely to a not-yet-adopted draft. Is the
   plan to fold a version of Michael's proposed text into -36, or to make the case to
   Deb directly that deferral to the companion draft is sufficient? Either is fine, but
   right now it reads as unresolved on both sides.

3. **Roman's fresh -35 comment (§13.5 IANA naming) — new, not yet answered.** His
   DISCUSS is cleared, but his 8/13 COMMENT on the informational-vs-standards-track
   naming inconsistency and Designated Expert asymmetry is a new ask on -35 text, not a
   leftover from -34. Worth a reply even though it's non-blocking, so it doesn't sit
   for a full revision cycle before anyone responds.

4. **Terminology / "imprinting" title-change thread** — useful discussion, but as of
   8/13 it hasn't converged into an actual text proposal. If this is meant to help
   close out Deb's clarity/terminology comments, it needs to land in -36 as concrete
   diffs, not stay as list consensus-forming.

Before I consider moving this forward, I want (2)
resolved in text or explicitly discussed with Deb directly, and (1) explicitly confirmed
by Eric rather than left to infer from a stale-looking ballot position — those are the
two items actually holding this up. The rest are not blocking but would be nice to address.

Thanks.


> On Aug 7, 2026, at 11:56 AM, Deb Cooley <[e-mail]> wrote:
> 
> Just to address the HSS/LMS question:  Yes, that is a fine idea. [The issue in that space is the inability to move the keys to prevent loss due to hw failure.  But I haven't tracked that issue in the last couple of years.  You may have more recent information.]
> 
> I  would be shocked to find out that ML-DSA isn't implemented by many HSMs (although I have not checked).  I'm less sure about a hybrid ML-DSA implementation (although many of those vendors are following both lamps and tls).
> 
> On Fri, Aug 7, 2026 at 2:30 PM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi, I've split your Comments up into subissues:
>>    https://github.com/anima-wg/voucher/issues/152
>> 
>> I will add a subsection to Security Considerations about Transition to
>> Quantum-Safe methods.
>> 
>> Some co-authors are vacationing, but are pushing edits to the PRs slowly.
>> 
>> There are a lot of components/dependancies that need to be considered, as a
>> CRQC could attack any of the links.
>> 
>> Fortunately, estimated 80% of them are under the control of the device
>> manufacturer, so they can effectively do them incrementally (if they wish)
>> and by fiat (without outside coordination).
>> 
>> HSS-LMS signatures could also be used my the MASA, I'm not sure if this is
>> worth suggesting.  At least today, I know multiple HSM vendors that support
>> it, which was not true a few years ago.
>> 
>> The other 20% is about the Registrar capabilities, and that component is
>> not constrained, does not live in box in a warehouse, and can be upgraded
>> easily.
>> 
>> 
>> --
>> Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> **       My working hours and your working hours may be different.         **
>> ** Please do not feel obligated to reply outside your normal working hours **
>> 
>> 
>> 
>> 


Mahesh Jethanandani
[e-mail]