SCITT Virtual Interim Meeting 26.06.2023

Minute taker: Hannes Tschofenig

Registration Policies

Jon & Hannes summarize the discussions related to registration policies

Jon proposes that the last few weeks of discussion point towards having
a very minimal approach to Registration Policies: set minimum
expectations and clearly define the role of the Registration Policy in
the architecture - particularly where they are evaluated - and then move
on. KISS for now.

Charlie suggests that working on these issues in a collaborative
document would be better. We agree in principlae but right now we dont'
have one so we'll do it in Hedgedoc today.

Jon clarifies that simple doesn't mean wishy-washy. We don't want to
specify deep syntax and complex requirements for Registartion Policies
but we DO need to be very specific and correct about which part of the
architecture evaluates it, for instance, and answer the question of
whether policies are per TS or per Feed or...

Yogesh agrees with Jon, and also says that there is other incorrect text
in the document. For example, he mentioned the storage of the
transparent statements in the registry. Yogesh offered to help with the
edits.

Ray says that he is concerned with the amount of the meta-data being
registered. He would like to have standard meta-data and extensions.
There also has to be some "side-method" to find the information. Ray
feels we're spending too much time on the cryptographic aspects when the
more imporant thing is the practical side of handling what will
ultimately become a massive Content Management System. We can't go back
to throwing emails around!

Ray wants to include information about

• the issuer,
• product name and version
• type of product

(Some of it would be application specific.)

In the end we need to have a way to search for something.

Hannes claims that the stated information is already available via the
application-specific payloas.

Ray argues that the payloads could be encrypted and that this approach
wouldn't work.

Roy believes the group is limited to three items. The ledger does not
see the data and efficiently index the data.

[Disagreement about how much functionality the ledger has to provide.]

Ray argues that an index is needed. Charlie agrees with him.

Ray suggests to add meta-data.

Roy believes applications will different indexing requirements. The
current version of the document defines a building block.

Jon: (Chair Hat Off) Agree with Ray. We submit a bunch of key value
pairs and optionally are searchable and indexable. This does not break
the application boundary. The difference between SCITT and the version
on top of it is that the layer above is able to efficiently search the
transparency service to get, for example, SBOMs without any violations
of the SCITT architecture.

Jon argues that the VRF is a good hackathon target - if we can prove we
can handle that 'usefully' then we answer the question. Note this
doesn't mean we want to define or standardize VRF per se, we just want
to show that the building blocks provide a useful foundation for such a
use case.

Orie: Don't understand what we are chartered to be working on. We said
that payloads are opaque. This is not inline with the hackathon target
with looking at the FDA use case. We have signed statements, receipts,
and RESTful APIs. If the group is attempting to standardize content
formats, like VRFs, then I am not sure it is possible to do in the group
under the current charter.

Jon + Hannes tried to explain the relationship between the standardized
work and the hackathon.

Dick: VRF is a contribution for the hackathon. Hannes asked me for a
good use case and I suggested the FDA use case because they require an
SBOM and a vulnerability disclosure program. It is a use case
representative for the SCITT architecture.

Henk: The API is about the issuance of signed statements and for
receiving receipts. Everyone wants to show value-add: building systems
in a hackathon is a good idea. The hackathon system will be
interoperable with the SCITT RESTful APIs. We should also discuss the
use cases. The core functionality of registering signed statements and
receiving receipts.

Orie: I am very supportive of the standards but I want to understand
what is in scope in the architecture.

Ray: In this working group we only need very little metadata support
defined. I was looking at the work by keytrans and they have one type of
data they are dealing with (public keys), and they still found the
needed a faster way to get to the data. For SCITT, there may be a group
or a sub-group that looks at a specific applications, like the software
use case, to define the metadata. This should fit easily into the
architecture already defined without drastic changes.

Dick: The term "opaque" payload is not the right payload. It would be
better to call it "agnostic" since the recipients need to understand
what they are consuming.

Roy: The issue that convolts this discussion and separation of Ledger
and a higher level product with indexing is the representation or marker
for Identity configuration. It puts a requirement on the higher level
layer to have to support a specific indexing\search scheme. The
bundling of a SCITT Notary under a product has the following
characteristics. 1) the audit of the log can find receipts to things
that are no longer available or failed a higher level RBAC construct,
and 2) must exist for long periods of time. Auditing or asking for a
refreshed receipts are all parts of where the ledger bleeds through a
product boundary. Asking for a receipt from a ledger does not
necessarily mean that the content (signature and receipt) are stored all
in the same system. I can envision mines "notarizing" their reports and
each supplying it to their consumers only. This does not take away from
the value of the receipt mechanisms. The core thing we need to ensure is
that the formats for intake and handing out are all cross product. If
RVST or another product bundles a Ledger under the covers this
interoperability is a prime concern.

Ray: I don't think that providing metadata forces any search scheme but
simply provides indexable data to work with in the cases when the
artifacts are not already self-describing.

Eduardo: We have certain type of headers, such as type of payloads. Q:
why isn't this enough?

Ray: A transparency service may need to have metadata to allow different
types of content to be supported. A viewer of the data should have the
ability to find metadata if it exists. Indeed, an SBOM is metadata but
it is also in a structured format, and so it can be referred to as a
whole. If only SBOMS were in the transparency service, then we could
perhaps have the application layer dig into the payload to find out what
product the SBOM refers to. In this case, it would be possible. But
assume that the submission is a binary program that is proprietary and
it cannot be revealed. Then we need metadata describing that artifact,
because it is not self-describing. The payload could be split in that
case and part would be the metadata and the other part could be the true
payload. Then, we could say that the metadata, if it exists, is in the
first part of the payload.

The KEYTRANS effort found that they needed an ability to easily locate
the public key of a given user id. In their case, the content of the
merkle tree is uniform, and they don't need to pick and choose. But they
do have a user id that is useful to find the public key. This is
essentiall a secure key-value lookup.

Consider the case of a generalize SCITT service like that I described in
my skyview document. There may be indexing sevices that can help users
find data in the tree. I don't think we need to tightly integrate the
search functionality such as is proposed by KEYTRANS but instead rely on
higher-level services. Such services, if they are to be general in
nature, will need to know where indexable content is. Most content of a
SCITT log may be only signed statements of content that may not even be
included as a payload. That means it will be difficult to index, and so
any automated indexing services would fail.

For purposes of supporting such metadata, I think defining the place for
it, probably in the protected header, is enough in this group. The
location and basic metadata items should be defined, and generally I
find that very few metadata items are necessary to give the indexing
services an anchor to start their work. If they find the item has no
metadata, then the submitter would have to provide the information about
the entry outside the SCITT service. That brings in security concerns.
It will be better to include the metadata, if it is appropriate, in the
protected header for a given artifact. I guess if the artifact is
self-describing, like an SBOM, then all that need be said is that it is
an SBOM, perhaps an IANA media type.

But many items are not self describing, and thus metadata is required
outside the artifact. To be uniform, all artifacts MAY be required to
have basic metadata. If there is some reason the protected header should
be limited in use, then the payload can be split into metadata and
artifact. The result is essentially the same. I daresay there is no way
to avoid metadata but we can just provide a means to encapsulate it at
this level and then other work can define it.

I would rather that the Vendor Response File VRF not be used as is (but
it still might be), because it provides not only the metadata but also
links to SCITT entries where the artifacts are. Rather, for each product
in the list, a scitt entry can be provided where the metadata is
provided, and the VRF would be produceable based on the scitt entries.
For a given product in the list of products shown in the VRF, there
seems to be a requirement that the scitt entry also have the description
of that product, in terms of Licensee, ProductName, Version, even though
a given agency might have their own required format.

Given that the SCITT transparency service is regarding products in a
supply chain, providing the minimum of Licensee, ProductName, and
Version makes sense. Additionally, I suggest a "product category" and
IANA media type. Additional metadata can follow on optional basis, and
then the signed statement provided in the submission. The product
category may be better understood as describing any extension of
metadata for given use cases.

I have to admit there is an alternative architecture where the scitt log
manager has no provisions for metadata, and the approach is to provide
metadata in other scitt entries and then link the two with references.
The VRF file implies this architecture. Then, we would still need to
somehow know the difference between items that are self-describing with
possible links to other scitt items that are not. I worry about this
architecture because it would introduce hazards and possible conflicts
in the metadata that is not encapsulated with the data item. Therefore,
I don't support this architecture, but if there are VRF that redundantly
provide metadata, then the metadata encapsulated with the item would
dominate.

I propose that we add text that registration policies may require that
metadata is provided with any artifact that is submitted. I'm not sure
but it is my guess that the metadata can be included in the protected
header. Alternatively, we can split the payload into two, with the first
part being metadata and the second part being the raw artifact (signed
statement). That may allow for more verbosity in the metadata that may
not be easily supported in the protected header.

----- Text Proposal -----

5.2.2. Registration Policies

A Transparency Services that accepts to register any valid Signed
Statement offered by anonymous Issuers would end up providing only
limited value, or no value, to verifiers. As a consequence, some form of

"verification" is needed before registration of Signed Statements to
ensure completeness of audit. More advanced use case will rely on the
Transparency Service performing additional domain-specific checks before

a Signed Statement is accepted. For example, some Transparency Services

may validate the content of Signed Statements.

We use the term "registration policies" to refer to the checks that are

performed before a Signed Statement is registered given a set of input
values. This baseline specification leaves the implementation of the
registration policy to the provider of the Transparency Services and its

users.

As a minimum we expect that a deployment authenticates the Issuer of the

Signed Statement, which requires some form of trust anchor. As defined
in [RFC6024] and [RFC9019], "A trust anchor represents an
authoritative
entity via a public key and associated data. The public key is used to
verify digital signatures, and the associated data is used to constrain

the types of information for which the trust anchor is authoritative."
The Trust Anchor may be a certificate, a raw public key or other
structure, as appropriate. It can be a non-root certificate when it is a

certificate.

A provider of a Transparency Service is, however, expected to indicate
what registration policy is used in a given deployment and inform its
users about changes to the registration policy.