[Rats] Re: draft-ietf-rats-multi-verifier-00: corrections to the cell table

[Joel Hillier <[e-mail]>]

Hi everyone,

Todd Kirton went back through the -00 text and checked my cell table of 4 September against Sections 6 and 7 rather than Section 5 alone. He is right on three cells and partly right on four more. The corrections are below, and they are his findings rather than mine.

The table read Section 5 as if it were the whole document. It is not, and Section 7.3 carries normative requirements that decide three of the cells against what I published.

WITHDRAWN

  H3  Unprotected Partial Evidence.  WITHDRAWN.
      I rested this on Section 5.1's "may wrap the Partial Evidence ... in a
      signed Conceptual Message Wrapper (CMW)". Section 7.3.1.1.3, Evidence
      Integrity and Origin Authentication (LV -> CV), says: "The LV MUST sign
      the Partial Evidence using a key that the CV trusts. This prevents any
      on-path attacker from altering the Partial Evidence." Protected and
      unprotected Partial Evidence are not two permitted end states under the
      document as a whole. The cell does not collapse.

  H4  Freshness, hierarchical.  WITHDRAWN.
      I rested this on Section 6's "the Verification of Freshness should be
      checked by the Lead Verifier". Two things are wrong with that. Section
      7.3.1.1.5, Replay Attacks, says: "The LV is responsible for enforcing
      freshness (via nonces, epochs, or timestamps). This freshness value
      MUST be propagated to CVs and back to the LV, to ensure final AR can be
      validated against the original challenge." And the "should" I quoted is
      lowercase, so under the document's own BCP 14 statement, which carries
      the "when, and only when, they appear in all capitals" clause, it was
      never normative in either direction. I treated a word with no normative
      weight as a weak requirement. The cell does not collapse.

  C4  Freshness, cascaded.  THE DOWNSTREAM HALF IS WITHDRAWN.
      I said the guarantee holds at the head and fails downstream, because
      5.2.3 lets the Relying Party enter anywhere. Section 7.3.2.1.4, Replay
      Attacks, says: "The first Verifier in the chain (the one receiving
      evidence from the Attester/RP) is responsible for enforcing freshness
      (via nonces, epochs, or timestamps) for the entire cascade. This
      freshness value MUST be propagated with the Evidence and Results
      through the chain." The freshness value travels with the results, so a
      Relying Party entering at Verifier 3 holds it. What the text does not
      require is that the results name which Verifier established it. That is
      a provenance question and it is narrower than what I published. Todd
      Kirton drew that distinction and it is his.

RESTATED, NOT WITHDRAWN

  H1, H2, C1, Y1 were published as COLLAPSES. They should read as permits a
  lossy profile, which is a weaker claim and a more accurate one.

      The draft says it "only covers the architectural aspects introduced by
      the Multi Verifier concept, which is neutral with regard to specific
      wire formats, encoding, transport mechanisms, or processing details",
      and it defines an Aggregated Attestation Results as "a collection of
      Attestation Results". Absence of a Section 5 requirement to carry a
      distinction is therefore not proof that the architecture collapses it.
      It shows the architecture does not prevent a profile from collapsing
      it. For a document that is deliberately architecture-only, that is the
      finding that is available, and it is the one an author can act on.

STANDING

  C2  Who aggregates and who signs.  STANDS, and Todd Kirton strengthened it.
      Section 7.3.2.1.3, Evidence and Results Protection, says "Partial and
      Aggregated Attestation Results SHOULD be signed by the Verifier that
      generated them", which sits alongside 5.2's aggregating verifier and
      signing verifier being different entities. The provenance question is
      about which Verifier is asserting which part of the aggregate.

  C3  Relying Party entry point.  STANDS. Not addressed by Section 7.

  H5, C5  Still acquitted, for the reasons given the first time.

THE CORRECTED COUNT

Eleven cells. Two withdrawn outright, one narrowed to a provenance question, four restated as permissive rather than mandatory, two standing, and two acquitted at the start and still acquitted. The arithmetic in my 4 September message, eight collapse and two do not and one partial, is superseded by this one.

WHAT THE EXERCISE ACTUALLY SHOWED

The pattern I claimed still holds, but it points somewhere more useful than I had it. The cells that survive contact with the whole document are the ones Section 7.3 pins with a capitalised MUST. The cells that remain open are the ones where Section 5 describes what an entity does and no later section says what the result must carry. That is a smaller and more actionable finding than the table claimed: the architecture is sound where it is normative and permissive where it is descriptive, and the gap between the two is where a profile can lose a distinction a Relying Party needs.

So the suggestion from the first message stands, narrowed. Rather than new machinery, a requirement that an Attestation Result names the ground it stands on: which component, appraised under whose policy, with freshness established where, and with the evidence protected or not. Section 7.3 already supplies three of those four for the hierarchical case. It is the naming that is missing rather than the guarantee.

Todd Kirton also sharpened the test itself, and his formulation is better than mine. A collapse finding needs three things: materially different upstream conditions, the same downstream-observable result, and a downstream decision that would act differently if it knew the distinction. My version asked for the first two and assumed the third. Several of these cells fail on the third, which is exactly why they should read as permits rather than does.

Happy to take any of the surviving cells into a PR rather than the list if the authors would rather work it there.

Best,

Joel
Certisyn, Inc.