Re: [SCITT] [Secdispatch] Request for session at IETF 113

[Kathleen Moriarty <[e-mail]>]

Greetings,

I have some similar questions, and question the hard requirement for a DID.
It seems that there will be many use cases that would want a traditional
PKI like is used with SigStore for a higher level of assurance. Both a
traditional PKI and a distributed can use the distributed ledger.

I am aware of vendors looking at this solution, so there's support behind
it. They also want to make sure the right thing is done, hence it coming to
the IETF to get broad review.

I think on the signature part, it would be useful to also support PKI with
ACME and to see the client authentication methods supported as sigStore
uses a certificate (their flow is a little different from ACME at the
moment).

I also support this being developed in the IETF as it's an important
problem set and now has vendor traction due to requirements. I'd just like
to see support for traditional PKI and ACME for the certificates/keys.

I have to go through the document more closely as the problem set needs to
consider organizations and individuals in terms of scale as well. How will
this be managed? Will it be manageable and can it be architected to reduce
the distributed burden so that security just works (as opposed to needing
another million jobs to be filled that can't be filled).

It's an important problem and would benefit from the IETF review process
and openness to bring more vendors together than those who are already
participating.

Best regards,
Kathleen

On Tue, Mar 22, 2022 at 7:31 AM Richard Barnes <[e-mail]> wrote:

> 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 <
> [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
>>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>


-- 

Best regards,
Kathleen