tags: ietf-scitt
\?

tags: ietf-scitt

IETF SCITT Periodic Meeting Agenda Draft

January 8, 2024

Agenda Items:

• Tightening up the archtiecture documents (quick review - Steve)

  • What's blocking the architecture? #148

    • Remove SCRAPI References #149

  • Some Header Re-Shuffeling #140

  • Draft Cleanup #150

• Consider clarifying "Verifier" and "Relying Party" #120 (A.J. &
  Monty)

• Complete Configuration/Registration Policy/Receipt Inclusion
  #151
• Improve introduction #143 (thgoebel)
• add your topics

Diff of changes from last time:
https://ietf-wg-scitt.github.io/draft-ietf-scitt-architecture/#go.draft-ietf-scitt-architecture.diff

Steve went through the dependency diagram that Orie maintains in the GH
Issue, Steve and Henk have added details.

Henk suggests a few more things are needed before we issue WGLC for the
architecture. Issue 148 tracking some of this: enks comment here on text
changes needed that are blocking architecture:
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/148#issuecomment-1881265948

AJ Asks where the dependency on the hash envelope comes from. Henk says
it's drawn in by SCRAPI since COSE doesn't quite provide all the
building blocks for a detached payload "by reference by hash" - that
requires an enhancement of Signed Statements/COSE-Sign1.

Henk: Proposal to move the
[draft-steele-cose-hash-envelope]((https://github.com/OR13/draft-steele-cose-hash-envelope)
draft to SCRAPI

Verifier & Relying Party update: A.J.: after reviewing, there were more
questions. Took the current state of the diagram from mermaid. Had some
questions on consumers and auditors as opposed to relying parties. Seems
a bit out of alignment with other specs, such as RATS. Would like to use
the term relying party, and verifier. Proposal to move away from
auditor, towards verifier and relying party.

Roy: Verifying of the ledger is a non-trivial role and we must ensure
that leveraging that role does not expose information from other
submitters. If the proof kept on the ledger is PAT then auditing gains
access and that would be bad in general.
If you want to stipulate that verifier only gets at inclusion proof then
that would side step my issue.

A.J. Auditor is frontloading a subjective term. Which may be incredibly
vague. Looking for direction to move forward with the issue.

Jon: Might want to make an explicit decision to avoid terms that are in
"near specs" to avoid confusion. Proposal to move the discussion to the
mailing list.

Steve: Configuration and Registration Policies. Summary of the state
from IETF 119. Goodness to have configuration and registration policies
captured in the receipt. However, the format of configuration and
regiration polices are implementation specific. Making it a challenge to
put partially defined infomration in the architecture.

Orie: should start from a question that this should not be in the
architecture doc, rather be implementation specific, including the
content-types. The only thing that needs tobe specified is the One True
Identifier for 'what is a Signed Statement' and 'What is a Receipt'?

Roy: The original intent from his perspective was to know when something
changed on the SCITT ledger. Simplest thought could be a monotonic
counter. If we just used an indicator "here's my state" that should do
it. We don't want to check Registration Policy on every receipt so we
just need a 'hint', and one that works with federated servers.

Ray agrees that the optimization refelcted by Roy's input would be very
good to have.

Steve: We seemt to agree on the value. Do we have enough clarity at this
point to include in the archicture, or add to SCRAPI or add to a future
version on the archicture.

Roy: all we need is some indicator in the receipt. If we try to actually
specify it in detail the discussion rat-holes too quickly so let's leave
it for a V2.