Meeting minutes for 2023-03-13

Chairs: Hannes will join later today so Jon G leading
Notes: Kiran K and (later) Hannes joining taking notes.

Agenda: Recent changes to Architecture, vast overhaul PR #16 etc.
Call for agenda hacking: no items.

Steve Lasker: captured issues from big merge and outstanding issues.
Triaged all outstanding and assigned important stuff to '116',
medium term stuff to '117' and unreviewed stuff no tag.

Small confusions with lots of small PRs in-flight (re-)introducing

Henk: Merged PR represents vast overhaul. COSE signing has 2 buckets-
metadata and non-metadata: This is somewhat remediated in the new PR
(see figure 1). There are still inconsistencies around certain terms. If
there is a concern with term- 'append-only ledger' term, please let us

Yogesh: We said we would replace ledger with log.

Henk: Registry has IETF connotation, ledger is also a burned term so
avoiding it here would be better. This can be discussed later as long as
we add more context. Append only log makes sense

Steve: If we're talking about an instance of this, is that a
transparency service?

Henk: Transparency Service includes log and concept of notarization

Ray: Log is not a great term because it already means something that has
simple line-by-line entries of the status of a process, errors,
activity, etc. "Logging" is not "Ledgering"

Steve: Statement (transparent, signed..) have been solved. logs vs
ledger will be discussed over time.

Jon: We have to draw the line somewhere and it has to be consistent.

Henk: At IETF116 we will review new SCITT Receipt ID representing all
COSE Merkle tree proofs next to COSE ID. We have to wait for responses
for COSE WG and there will be consolidation between 116 and 117. There
is a lot of churn. Should the architecture doc refer to the new ID?
General consensus is no. There should be no more changes to architecure
doc before today and IETF116

Charlie: Can we share link to the document? Also on terminology, we've
settled on statement, notarization?

Henk: There is no decision about where the receipt work will happen

Charlie: Why do we need to specify a signature method? Wouldn't any
signature method work?

Henk: No. Doing the authenticity check on a global scale is complicated
and requires specification work. That's why we picked COSE.

Charlie: Any standard would work?

Ray: I like ledger better for the core part of SCITT. Registry is better
as a term for the "whole thing". These are my opinions right now. Like
the discussion about how COSE fits in.

Henk: We have this "how to present this merkle tree graph". We cannot
have named algorithms (Amazon QLDB) without doing an exercise with CFRG
to get QLDB vetted. We have to go through the CFRG (crypto forum
research group) for the vetting of new algorithms. This will take a bit
of time. QLDB is on the radar.

Olle: We need an equivalent of UTA (Using TLS in applications) that
produce a BCP for signatures

Ray: I am used to use off-the-shelf things rather than using something
that is absolutely new.

Jon: The deadline for submission is today. Is there something in the
current spec we need to update today? Changing ledger to log is a bit
too generic.
We need to make sure that we are happy with the submission.

Henk: This is an open PR and we have not made any decision on this.

Ray: Ledger is much more meaningful and goes along with what we had in
mind. Log implies something else.

Dick: Registry is the proper term. I don't see any showstoppers for the
draft submission today. In ISO we faced a similar challenge regarding
the payload types. Defining a content type helps to address the way to
communicate different formats.

Henk: Media types are definitely in scope and if we carefully phrase
them then they are useful. Agree with Dick (although it might not be a
high priority right now).

Dick: there is no reason why we couldn't be using COSE, S/MIME, PGP,

Henk: For the payload-level I agree. On the authenticity we have to pick
something because of interoperability. If we allow multiple choices then
there will be a problem.

Dick: I hope that any transparency service can select the technologies
it wants to support.

Henk: There will be a nesting. There will be a domain-specific signature
in the SCITT signature. The SCITT signature will be the unifying. You
don't have to remove the domain-specific signature. This is OK. One the
SCITT level we cannot offer different choices.

Dick: You are saying we have to make a selection at the SCITT level.

Henk: Yes.

Ray: What are the show-stopper open issues that must be settled today?

Neal: Agree with Henk. I am not sure what you saying about the
append-only definition. I thought there was a single way to architect
this, at least from the auditors task. To what extend do we approve a
certain append-only data structure.

Henk: I don't think we can say "this is the way" but we have to do some
vetting. We can list technologies in an IANA registry, for example.

Neal: This is also an issue for the verifier of the receipt. I wonder
how far we should push the standardization of the append-only log and
other issues relevant to consumers and verifiers.

Yogesh: I don't think there is anything block regarding the submission
today (architecture). Regarding the append-only discussion: Relating it
too much to the Merkle-Tree technology is too restrictive because there
may be other technologies may come up later. Merkle-Tree is an
implementation of the append-only log.

Jon: Agree. There is also a need to specify how to achieve log

Steve: Issue regarding Log and Ledger:

Steve: The document refers to append-only log. Describing the
characteristics is more important than the specific term.

Ray: Agree with Steve. It would be good to allow other implementations.

There aren't any serious open issues with the architecture document

Steve: There are a few clarifications I hope to get done today. The
document is in pretty good shape. We continue to make great progress.
What is the next steps between now and the IETF meeting?

Hannes: There is black-out period till the IETF meeting. There is the
expectation that everyone reads the documents for the meeting.

Steve: To create stability for 116, I'll re-assign all 116 items to 117

Henk: Adds further details about the draft submission practices.

Jon: I wouldn't want to make some last minute changes. We can discuss
them in subsequent meetings.

Charlie: Agree with Jon. It is not a big deal. My request is to specify
the behavior we want rather than the implementation.

Henk: This is something for the meeting to discuss. Agree with Charlie.
We should allocate discussion time at the meeting.

Hannes explained the next steps: Submission of use case and architecture
document today. Another meeting next Monday.

Yogesh: Should we discuss the presentations here?

Henk: No, not necessary.

Hannes: Pick some open issues (we seem to have enough).

Dick: I sent a link to the list about the US Cyber Security Strategy to
the use case draft.

Charlie: I wouldn't do it.

Hannes: I would do it if you think it is useful.

Dick: I think it is aligned with what we have in the use case document.

Charlie: It is not a perfect match for SCITT. I think it is orthogonal.

Dick: I see it differently.

Olle: Adding only the US strategy is not great. We should add other
countries/regions as well.