Re: [Secdispatch] Request for session at IETF 113

Richard Barnes <rlb@ipv.sx> Tue, 22 March 2022 11:31 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDA33A110C for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 04:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxZJqUonsob1 for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 04:31:37 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C463A112A for <secdispatch@ietf.org>; Tue, 22 Mar 2022 04:31:16 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id k125so13749037qkf.0 for <secdispatch@ietf.org>; Tue, 22 Mar 2022 04:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dx36XK0Leu4BsDOewduCjJHLYPmbnHANJzqpgIW8ShE=; b=wSA9COxwGFF0tbblv6A6y0mhWat1BXJnvZNPuDeG2oDezVxJNBIMgGNxrd/PST3gej 5eycBuc9NxsDCoe+PQ//f65FiuHYwwJqp2DaXzF0YdrTFIplzLzTJ/V7em5w/Dt6Xzqp xzKo6Wi++63P37g5SSTrUJHphCTxlO9cdpcRSP42QBGRc21iK0MRv1duA2MJ/Vp9JvJh LxFrMYerUSz3O0wEIJ0dHOimSM2bdLl4pAN7HKdgESGGWkbASa8iSi4D6d80Pc0nVMdy d9Uo64lf09w/bsOmt580umwvmg3t6rijEZCMWy4wbPVW3UpD5DZCZuNwqHiSkjjuPH43 W+KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dx36XK0Leu4BsDOewduCjJHLYPmbnHANJzqpgIW8ShE=; b=AedKUJN+E/UfljDLrwnOHutMXVGNRqHkCXNoH4cNj6JaGGiem7gPGnRqQOAhpfKEm/ cLdPMiHDOKBlGlC6ztQWfULwt/Yt9UI24Xe9pglEFmnux/uw8pjMruMto3hSofPTzByY huyt4SN8clYFcDoM0ea+8dZPMrkUFenEX8EMLaQURdI2cGFfjbyXL+yDYBy/PUWpUSOb m438sOphezH3ZKh9u8h1eoD3Qor2YuW71hMP7yb+eVcHijLVTQl6GUnAMXkWg5+SLVxi 6ubnZVAnBzlvODbk6Gg/mW7wTXmAtuJohsYZb1mncI9cIixizfJZp8mmSDIX7Wt6ULc/ M3qw==
X-Gm-Message-State: AOAM530e9AncpRu9GlTEyUEXMxa+0C+7IGCrb/TdRULsr9v9GHuQYgz+ 7KV9g8NkkRw+LQVnOjh8Tf/RawCq51dZ3k7H7WKP5A==
X-Google-Smtp-Source: ABdhPJx6hfpq/SKk3r7rw/dKITfZPOdmPWjmVTQeQU1dAabiC1oLFge/c5/yJvy9JIXnK84nm7LEEw2sIMS9kxPyQUw=
X-Received: by 2002:a37:a0ca:0:b0:67d:b628:6a4e with SMTP id j193-20020a37a0ca000000b0067db6286a4emr15174967qke.35.1647948675151; Tue, 22 Mar 2022 04:31:15 -0700 (PDT)
MIME-Version: 1.0
References: <164583895227.24617.1939040203283436909@ietfa.amsl.com> <5b97a678-eba1-09c3-7e70-c71dd98db8a9@sit.fraunhofer.de>
In-Reply-To: <5b97a678-eba1-09c3-7e70-c71dd98db8a9@sit.fraunhofer.de>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 22 Mar 2022 07:31:04 -0400
Message-ID: <CAL02cgT7cRXsM7qNtMarcxcLd0fdSCtj_dM+79=DbnMWyikdhQ@mail.gmail.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: secdispatch@ietf.org, scitt@ietf.org
Content-Type: multipart/alternative; boundary="000000000000640ced05daccf3d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/uSPaVeOXUr3mW3d5biQGKJBKW50>
Subject: Re: [Secdispatch] Request for session at IETF 113
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 11:31:45 -0000

Hi folks,

It looks like at a high level, the approach here is along the same lines as
what has been discussed as "Binary Transparency" elsewhere.  There have
been several stabs taken at this before.  See, for example:

https://www.sigstore.dev/
https://unmitigatedrisk.com/?tag=binary-transparency
https://github.com/FreeBSDFoundation/binary-transparency-notes/blob/master/debian.txt
https://wiki.mozilla.org/Security/Binary_Transparency

While these existing approaches do help validate that there is some
interest in the field for what SCITT does, it's not clear how SCITT is
different from / better than this prior art.

--RLB


On Wed, Mar 9, 2022 at 5:40 PM Henk Birkholz <
henk.birkholz@sit.fraunhofer.de> 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
> > Secdispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdispatch
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>