Re: [Secdispatch] Request for session at IETF 113

[Eric Rescorla <[e-mail]>]

OVERALL
This document describes a general structure for providing transparency
for  software artifacts, effectively a generalization of what's often
called "binary transparency". This is a useful kind of service in concept
an at least theoretically an appropriate topic for IETF.

The answer to the secdispatch questions depends, I think on the level
of interest people have in deploying such a service and especially
with this as a starting point. Specifically, we'd need to hear from:

- Software vendors
- Potential transparency service (log) operators.

I'd particularly like to hear from people who already are involved
with Binary Transparency:
https://developers.google.com/android/binary_transparency

If there is interest, I would be supportive of moving forward with
this. Given the complexity of the topic, a BOF is probably the next
step.


TECHNICAL
I do have a few small technical comments.

1. I'm still working through the semantics of the identities you are
   using. As I understand it, the signatures are intended to provide
   evidence that the vendor actually published something, but if you
   use did:web, then can't the vendor just use a different key for
   each signature and remove the key from the Web site later. What
   proof is there that the vendor endorsed a specific key?

2. I understand the appeal of the append only log, but I'd observe
   that much of the value in CT has been achieved without any real
   verification by clients of the inclusion proofs but just relying
   entirely on SCTs. So, perhaps we don't need to try as hard
   here. This point applies to BT as well, I think.

3. S 6.3 seems to require the claim to be appended to the log prior to
   issuing the receipt. This is not how CT is architected, as I
   understand it because of concerns about the latency of that
   process. Instead, certificates have SCTs. Do similar concerns
   apply here?

I'm sure all of these could be addressed during the standards process,
and they certainly don't preclude doing this work, but I noted them
as I read the document and thought it would be good to record them.









On Wed, Mar 9, 2022 at 2:40 PM Henk Birkholz <
[e-mail]> wrote:

> Hi secdispatch,
> (hi scitt),
>
> emerging work on the topic of Supply Chain Integrity, Transparency,
> Trust has taken some shape recently.
>
> The work combines existing IETF building blocks to facilitate useful
> Internet-based support of global supply chain interoperability.
>
> Current contributions focus on the definition of Transparency Services
> based on Internet technology (using CBOR/CDDL/COSE) to achieve
> unambiguous, scaleable, and resilient integration with common devops and
> secops requirements.
>
> I'd like to request secdispatch agenda time for two documents that are
> currently submitted:
>   > https://datatracker.ietf.org/doc/draft-birkholz-scitt-architecture/
>
> and
>
> > https://datatracker.ietf.org/doc/draft-birkholz-scitt-receipts/
>
> These two contributions are in -00 state. Yet, they already address
> essential requirements, such as, air-gapped validation when being
> offline, integration of remote attestation, efficient and crypto-agile
> signing prescriptions for out-of-the-box interoperability, and - in
> essence - long-long-term guarantees in support of various types of
> supply chains requirements.
>
> We’d be happy to present this emerging work in secdispatch with the goal
> of discussing whether it might fit into the IETF space and how to
> progress it together.
>
> Viele Grüße,
>
> Henk
>
>
>
> On 26.02.22 02:29, "IETF Secretariat" wrote:
> > Dear Mohit Sethi,
> >
> > The session(s) that you have requested have been scheduled.
> > Below is the scheduled session information followed by
> > the original request.
> >
> >
> >      secdispatch Session 1 (2:00 requested)
> >      Tuesday, 22 March 2022, Afternoon Session II 1430-1630
> >      Room Name: Grand Park Hall 3 size: 250
> >      ---------------------------------------------
> >
> >
> > iCalendar:
> https://datatracker.ietf.org/meeting/113/sessions/secdispatch.ics
> >
> > Request Information:
> >
> >
> > ---------------------------------------------------------
> > Working Group Name: Security Dispatch
> > Area Name: Security Area
> > Session Requester: Mohit Sethi
> >
> >
> > Number of Sessions: 1
> > Length of Session(s):
> > Number of Attendees: 200
> > Conflicts to Avoid:
> >
> >
> >
> >
> > People who must be present:
> >    Benjamin Kaduk
> >    Kathleen Moriarty
> >    Mohit Sethi
> >    Paul Wouters
> >    Richard Barnes
> >    Roman Danyliw
> >
> > Resources Requested:
> >
> > Special Requests:
> >    Please avoid conflict with any Security related BoF.
> > ---------------------------------------------------------
> >
> >
> > _______________________________________________
> > Secdispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdispatch
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>