[{"author": "Eliot Lear", "text": "<p>Good morning/Good evening</p>", "time": "2023-07-24T16:30:25Z"}, {"author": "Eliot Lear", "text": "<p>and Good afternoon!</p>", "time": "2023-07-24T16:30:32Z"}, {"author": "Jon Geater", "text": "<p>Morning Eliot</p>", "time": "2023-07-24T16:32:11Z"}, {"author": "Jon Geater", "text": "<p>@Christopher Allen long time no see - good to see you here</p>", "time": "2023-07-24T16:32:37Z"}, {"author": "Dick Brooks", "text": "<p>Hello Everyone. Cheers.</p>", "time": "2023-07-24T16:32:47Z"}, {"author": "Jon Geater", "text": "<p>Hi Dick</p>", "time": "2023-07-24T16:33:03Z"}, {"author": "Christopher Allen", "text": "<p>Are these links on slides live anywhere in tulip/meetco</p>", "time": "2023-07-24T16:34:54Z"}, {"author": "Dick Brooks", "text": "<p>I received a congratulatory note from Jessica Wilkerson at FDA today on our Hackathon success. Well done everyone! CISA is also going to mention the Hackathon success in an upcoming newsletter.</p>", "time": "2023-07-24T16:35:35Z"}, {"author": "Christopher Allen", "text": "<p><a href=\"https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/\">https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/</a></p>", "time": "2023-07-24T16:37:11Z"}, {"author": "Jon Geater", "text": "<p>All the meeting slides are inthe Meeting Materials section of Meetehco / Data Tracker</p>", "time": "2023-07-24T16:37:14Z"}, {"author": "Christopher Allen", "text": "<p><a href=\"https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/\">https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/</a></p>", "time": "2023-07-24T16:37:43Z"}, {"author": "Dick Brooks", "text": "<p>Jon, were you able to update the hackathon slides with screen shots from my test?</p>", "time": "2023-07-24T16:37:47Z"}, {"author": "Michael Prorock", "text": "<p><a href=\"https://www.iso.org/standard/50276.html\">https://www.iso.org/standard/50276.html</a></p>", "time": "2023-07-24T16:38:00Z"}, {"author": "Adam Wiethuechter", "text": "<p>Is mic on?</p>", "time": "2023-07-24T16:39:37Z"}, {"author": "Adam Wiethuechter", "text": "<p>Ah there he is</p>", "time": "2023-07-24T16:39:41Z"}, {"author": "Michael Prorock", "text": "<p>the camera tracking is hilarious</p>", "time": "2023-07-24T16:40:58Z"}, {"author": "Michael Prorock", "text": "<p>i think it doesn't like british accents</p>", "time": "2023-07-24T16:41:11Z"}, {"author": "Adam Wiethuechter", "text": "<p>The door is speaking</p>", "time": "2023-07-24T16:41:16Z"}, {"author": "Lorenzo Miniero", "text": "<p>:)</p>", "time": "2023-07-24T16:41:34Z"}, {"author": "Lorenzo Miniero", "text": "<p>Sorry about that!</p>", "time": "2023-07-24T16:41:45Z"}, {"author": "Adam Wiethuechter", "text": "<p>I'm surprised it didn't do a full 360 to get a bearing of its surroundings :p</p>", "time": "2023-07-24T16:42:19Z"}, {"author": "Neal McBurnett", "text": "<p>Mention was made of some related ISO efforts. But I'm very interested in the lastest thinking on how SCITT relates to SigStore: what use cases it addresses that SigStore does not.</p>", "time": "2023-07-24T16:47:09Z"}, {"author": "Hannes Tschofenig", "text": "<p>Good question, Neal. Will bring it up later in the discussion</p>", "time": "2023-07-24T16:50:33Z"}, {"author": "Dick Brooks", "text": "<p>Registered Statement!</p>", "time": "2023-07-24T16:53:23Z"}, {"author": "Yogesh Deshpande", "text": "<p>Also, we should discuss how we are making efforts to bring KEY TRANS group to come on board with SCITT</p>", "time": "2023-07-24T16:55:06Z"}, {"author": "Raymond Lutz", "text": "<p>I'm here</p>", "time": "2023-07-24T16:56:09Z"}, {"author": "Neal McBurnett", "text": "<p>Hi, Ray!</p>", "time": "2023-07-24T16:56:38Z"}, {"author": "Yogesh Deshpande", "text": "<p>Our Architecture is fully flexible to absorb other use cases</p>", "time": "2023-07-24T16:58:40Z"}, {"author": "Dick Brooks", "text": "<p>I agree @Yogesh I beleive SCITT can support all the use cases we cite in the Use Case document, including the new IoT Cybersecurity Trust Mark Lable</p>", "time": "2023-07-24T17:00:13Z"}, {"author": "Roman Danyliw", "text": "<p>Reuse by other verticals of the SCITT technology would be wonderful.  However, standardizing any verticals beyond software in not in scope.</p>", "time": "2023-07-24T17:00:49Z"}, {"author": "Dick Brooks", "text": "<p>+1 Roman</p>", "time": "2023-07-24T17:01:10Z"}, {"author": "Yogesh Deshpande", "text": "<p>Yes agree with Roman, however, at some point in future, we should revisit SCITT Charter to see if we can widen the scope of SCITT..</p>", "time": "2023-07-24T17:02:35Z"}, {"author": "Dick Brooks", "text": "<p>I agree with Jon. The SLSA/SigStore folks can provide a use case, just liek th eFDA use case was proposed.</p>", "time": "2023-07-24T17:02:39Z"}, {"author": "Dick Brooks", "text": "<p>The SCITT Hackathon showed how a \"public registry\" could be implemented for software supply chain data exchange, just like a \"Registry of Deeds\" provides public access to land records..</p>", "time": "2023-07-24T17:06:32Z"}, {"author": "Eliot Lear", "text": "<p>Chris it might be good to write an \"SCITT Abuse Case\" draft</p>", "time": "2023-07-24T17:08:15Z"}, {"author": "Dick Brooks", "text": "<p>+1 Eliot - then we can study and discuss in the WG</p>", "time": "2023-07-24T17:09:07Z"}, {"author": "Neal McBurnett", "text": "<p>I don't think SigStore requires use of email addresses - discussed previously on the list IIRC</p>", "time": "2023-07-24T17:10:55Z"}, {"author": "Dick Brooks", "text": "<p>For privacy; there is nothing in SCITT that prevents a party from registering an encrypted/signed statement if privacy is a concern</p>", "time": "2023-07-24T17:11:45Z"}, {"author": "Christopher Allen", "text": "<p>We have a side-meeting today on requirements data formats that enable privacy, 15:30-17:00, Golden Gate 4 Room (seats 16). We have a rough start on problem statement <a href=\"https://hackmd.io/GqY8eZtMQQygjuAn3aj1Ow\">https://hackmd.io/GqY8eZtMQQygjuAn3aj1Ow</a></p>", "time": "2023-07-24T17:14:50Z"}, {"author": "Michael Prorock", "text": "<p>@ChrisAllen - is that during the dcbor side meet before the main cbor meeting?</p>", "time": "2023-07-24T17:16:21Z"}, {"author": "Christopher Allen", "text": "<p>We also have an Internet-Draft on Gordian Envelope that we believe demonstrates that this is possible at:</p>\n<p><a href=\"https://datatracker.ietf.org/doc/draft-mcnally-envelope/\">https://datatracker.ietf.org/doc/draft-mcnally-envelope/</a></p>", "time": "2023-07-24T17:16:38Z"}, {"author": "Michael Prorock", "text": "<p>+1 Roy</p>", "time": "2023-07-24T17:17:19Z"}, {"author": "Christopher Allen", "text": "<p><span class=\"user-mention\" data-user-id=\"2956\">@Michael Prorock</span> yes, it is before.</p>", "time": "2023-07-24T17:17:25Z"}, {"author": "Eliot Lear", "text": "<p>I think it'd be good to see a specific envisioned misuse of scitt, in detail.</p>", "time": "2023-07-24T17:17:46Z"}, {"author": "Dick Brooks", "text": "<p>+1 Roy and Jon - SCITT is payload agnostic</p>", "time": "2023-07-24T17:17:50Z"}, {"author": "Michael Prorock", "text": "<p>we also can't let perfect be the enemy of the good here in the sense that there are core regulatory requirements we must respond to, as best we can, but this stuff has to get deployed and used</p>", "time": "2023-07-24T17:18:00Z"}, {"author": "Cedric Fournet", "text": "<p>@Christopher Allen I won't be able to join this side meeting, but I am interested in catching up.</p>", "time": "2023-07-24T17:18:07Z"}, {"author": "Christopher Allen", "text": "<p><span class=\"user-mention\" data-user-id=\"974\">@Cedric Fournet</span> sure!</p>", "time": "2023-07-24T17:18:56Z"}, {"author": "Yogesh Deshpande", "text": "<p>Same here <span class=\"user-mention\" data-user-id=\"2371\">@Christopher Allen</span> <br>\nI cannot make it been in UK, but interested to chat on this subject</p>", "time": "2023-07-24T17:19:23Z"}, {"author": "Raymond Lutz", "text": "<p>Neal, perhaps sigstore does not require them but they are commonly used. SCITT can accommodate that method or really any other method which is essentially pushed up to a slightly higher level. I support essentially dodging the issue at this stage to get this layer done without any opinion made about what form of identity is to be used. A policy of what the policy for identity and submission to the registry can be submitted to the registry, as well as the identities that are currently used, etc.  So SCITT can handle really any type of identity regime.</p>", "time": "2023-07-24T17:20:12Z"}, {"author": "Raymond Lutz", "text": "<p>The scitt registry can be used to help solve the identity problem.</p>", "time": "2023-07-24T17:21:19Z"}, {"author": "Christopher Allen", "text": "<p><span class=\"user-mention\" data-user-id=\"1181\">@Yogesh Deshpande</span> I\u2019m available at <a href=\"mailto:ChristopherA@LifeWithAlacrity.com\">ChristopherA@LifeWithAlacrity.com</a> and on Signal.</p>", "time": "2023-07-24T17:21:45Z"}, {"author": "Dick Brooks", "text": "<p>FYI: The FDA requirements that were shown in the Hackathon Use Case are here: <a href=\"https://mailarchive.ietf.org/arch/msg/scitt/fEzHB0fMYPqnmNaZuoHjIK_v_QU/8/\">https://mailarchive.ietf.org/arch/msg/scitt/fEzHB0fMYPqnmNaZuoHjIK_v_QU/8/</a></p>", "time": "2023-07-24T17:22:21Z"}, {"author": "Dick Brooks", "text": "<p>The detailed description of the FDA Use Case shown in the SCITT HAckathon implementation is shown here: <a href=\"https://mailarchive.ietf.org/arch/msg/scitt/fEzHB0fMYPqnmNaZuoHjIK_v_QU/7/\">https://mailarchive.ietf.org/arch/msg/scitt/fEzHB0fMYPqnmNaZuoHjIK_v_QU/7/</a></p>", "time": "2023-07-24T17:23:34Z"}, {"author": "Eliot Lear", "text": "<p>Ok, let's get the city name right on the slide!!</p>", "time": "2023-07-24T17:24:41Z"}, {"author": "Roy Williams", "text": "<p>Ouch</p>", "time": "2023-07-24T17:28:27Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"350\">Eliot Lear</span> <a href=\"#narrow/stream/300-scitt/topic/ietf-117/near/78480\">said</a>:</p>\n<blockquote>\n<p>Chris it might be good to write an \"SCITT Abuse Case\" draft</p>\n</blockquote>\n<p>With my SecDir hat on, +100 for a document <em>\"We're building a dangerous thing; here's how it needs to NOT be used\"</em>.</p>", "time": "2023-07-24T17:28:29Z"}, {"author": "Raymond Lutz", "text": "<p>Probably better not to use VRF for Vendor Response File because it is too confusing. vendor product disclosure VPD maybe.</p>", "time": "2023-07-24T17:29:18Z"}, {"author": "Eliot Lear", "text": "<p>@Mike: yes.  My point is this: if the primitives are causing problems and there are ways to correct them, now is a good time to deal with that.</p>", "time": "2023-07-24T17:29:21Z"}, {"author": "Adam Wiethuechter", "text": "<p>An \"Abuse Cases\" draft would also be good ground work for someone to look for ways to detect such abuses and deny them.</p>", "time": "2023-07-24T17:29:28Z"}, {"author": "Eliot Lear", "text": "<p>but we need to understand if that's the case</p>", "time": "2023-07-24T17:29:36Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention\" data-user-id=\"350\">@Eliot Lear</span> I'm a tourist and don't know the SCITT architecture, but my gut feeling is that the building blocks are fine, but cease to be fine if you're logging the UPN of every dev who contributed code, and the state of their apt installed packages, and what they had for lunch. Anyone who tries to define a statement format like that needs to be pelted with suitably hard and pointy objects. An IETF \"Don't do this\" document that such a statement format is clearly violating is probably the best we can do?</p>", "time": "2023-07-24T17:32:20Z"}, {"author": "Henk Birkholz", "text": "<p>Thank you 4 volunteering!</p>", "time": "2023-07-24T17:32:21Z"}, {"author": "Dick Brooks", "text": "<ul>\n<li>Henk</li>\n</ul>", "time": "2023-07-24T17:32:42Z"}, {"author": "Christopher Allen", "text": "<p>Here is a W3C use case on protecting engineer\u2019s identity in software supply chain: <a href=\"https://w3c-ccg.github.io/amira/\">https://w3c-ccg.github.io/amira/</a>  Here is a an example of how to implement it with Gordian: <a href=\"https://github.com/BlockchainCommons/Gordian/blob/master/Envelope/Use-Cases/Software.md\">https://github.com/BlockchainCommons/Gordian/blob/master/Envelope/Use-Cases/Software.md</a></p>", "time": "2023-07-24T17:32:45Z"}, {"author": "Dick Brooks", "text": "<p>+1</p>", "time": "2023-07-24T17:32:47Z"}, {"author": "Hannes Tschofenig", "text": "<p>Thanks for sharing this work from the W3C, Christopher.</p>", "time": "2023-07-24T17:33:31Z"}, {"author": "Raymond Lutz", "text": "<p>@Mike Ounsworth -- I agree and the idea here is the difficult identity issue is pushed up to slightly higher layer with knowledge that the immutable log may be used to solve some of those issues.</p>", "time": "2023-07-24T17:34:14Z"}, {"author": "Christopher Allen", "text": "<p>Has there been any progress on moving past x.509 and ASN.1?</p>", "time": "2023-07-24T17:35:44Z"}, {"author": "Dick Brooks", "text": "<p>Current software supply chain practices are heavily reliant on PGP and X.509 for digital signatures.</p>", "time": "2023-07-24T17:37:02Z"}, {"author": "Michael Prorock", "text": "<p>apologies to orie for handing him and extra slide</p>", "time": "2023-07-24T17:37:21Z"}, {"author": "Raymond Lutz", "text": "<p>@Christopher Allen:<br>\nThe use of COSE in SCITT may allow us to slowly reduce reliance on X.509/ASN.1</p>", "time": "2023-07-24T17:38:03Z"}, {"author": "Michael Prorock", "text": "<p>+1 cose is starting to give us a path forward, but we need to wait for / continue to move things along to the path to RFC so we can leverage it</p>", "time": "2023-07-24T17:38:40Z"}, {"author": "Michael Prorock", "text": "<p>right now we use the tools we have</p>", "time": "2023-07-24T17:38:48Z"}, {"author": "Michael Prorock", "text": "<ul>\n<li>gets stones together in a pile *</li>\n</ul>", "time": "2023-07-24T17:39:44Z"}, {"author": "Dick Brooks", "text": "<p>Spot On Orie!</p>", "time": "2023-07-24T17:41:39Z"}, {"author": "Christopher Allen", "text": "<p>There is also <a href=\"https://www.ietf.org/mailman/listinfo/cwp\">https://www.ietf.org/mailman/listinfo/cwp</a> </p>\n<p>Discussion venue on trying to design for a future certificate type that can be used with post quantum algorithms that does not use PKIX.</p>", "time": "2023-07-24T17:44:29Z"}, {"author": "Michael Prorock", "text": "<p>good points on attakc surface - registration policies as discussed in the architecture doc help there</p>", "time": "2023-07-24T17:51:12Z"}, {"author": "Dick Brooks", "text": "<p>Support for software supply chain in SCITT will likely require the ability id identify a specific software product/version from a uniquely identified Software Supplier : i.e. pkg:swid/ACME/dns:<a href=\"mailto:acme.com/HelloWorld@1.0\">acme.com/HelloWorld@1.0</a></p>", "time": "2023-07-24T17:53:32Z"}, {"author": "Henk Birkholz", "text": "<p>RFC 7320</p>", "time": "2023-07-24T17:56:21Z"}, {"author": "Henk Birkholz", "text": "<p>\"get off my lawn\"</p>", "time": "2023-07-24T17:56:50Z"}, {"author": "Darrel Miller", "text": "<p>and updated by RFC8820</p>", "time": "2023-07-24T17:57:16Z"}, {"author": "Roman Danyliw", "text": "<p>/.well-known/ = RFC785.  Per @Lear, concur.  formalizing a URL structure which doesn't use .well-known will get a DISCUSS during IESG review.</p>", "time": "2023-07-24T17:58:39Z"}, {"author": "Roman Danyliw", "text": "<p>rfc5785</p>", "time": "2023-07-24T17:59:33Z"}, {"author": "Jon Geater", "text": "<p>Link: <a href=\"https://datatracker.ietf.org/doc/html/rfc5785\">https://datatracker.ietf.org/doc/html/rfc5785</a></p>", "time": "2023-07-24T18:02:22Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"2371\">Christopher Allen</span> <a href=\"#narrow/stream/300-scitt/topic/ietf-117/near/78736\">said</a>:</p>\n<blockquote>\n<p>There is also <a href=\"https://www.ietf.org/mailman/listinfo/cwp\">https://www.ietf.org/mailman/listinfo/cwp</a> </p>\n<p>Discussion venue on trying to design for a future certificate type that can be used with post quantum algorithms that does not use PKIX.</p>\n</blockquote>\n<p>No activity on that list since Mar :(<br>\nI really _really_ want to know what the alternatives are!</p>", "time": "2023-07-24T18:02:27Z"}, {"author": "Dick Brooks", "text": "<p>CPE's are a big problem. Please consider purl instead for SW ID;  pkg:swid/ACME/dns:<a href=\"mailto:acme.com/HelloWorld@1.0\">acme.com/HelloWorld@1.0</a></p>", "time": "2023-07-24T18:02:57Z"}, {"author": "Jon Geater", "text": "<p>Thanks Dick. These are 2 separate thorny problems: is pURL better than CPE for software identification, and is either of them a good model for Feed identifier?</p>", "time": "2023-07-24T18:04:01Z"}, {"author": "Dick Brooks", "text": "<p>TBD, Jon. We should definitely discuss pros/cons and other options.</p>", "time": "2023-07-24T18:04:32Z"}, {"author": "Eliot Lear", "text": "<p>In my review, I will tell you that the biggest issue I will tackle is whether I understand the concept of a feed.</p>", "time": "2023-07-24T18:04:59Z"}, {"author": "A.J. Stein", "text": "<p>It was an explanation of a common use case that others at the Hackathon wanted, not because it is everyone's favorite (not mine either, and I worked on it). Since you all seem familiar, trying to map CPE&lt;-&gt;CDX/SPDX or other SBOM formats by pURL is not an easy two-day Hackathon problem.</p>", "time": "2023-07-24T18:06:00Z"}, {"author": "Dick Brooks", "text": "<p>Are feeds only used for inter-registry communications or is it also used to registry a new artifact?</p>", "time": "2023-07-24T18:06:45Z"}, {"author": "Dick Brooks", "text": "<p>The HAckathon produced a URL to the registered VRF. This URL enabled me to retrieve the SCITT registered VRF directly, without searching.</p>", "time": "2023-07-24T18:10:06Z"}, {"author": "Raymond Lutz", "text": "<p>There are many ways that different vendors describe their products -- some use structured identifiers and this make it somewhat easier to assign the value as long as all the attributes fit in the structure of the value. Others have given up and use just an arbitrary number or a hybrid that uses structure to a point, then using the arbitrary number. At this level, I don't think we can dictate the approach that can be used.</p>", "time": "2023-07-24T18:11:50Z"}, {"author": "Raymond Lutz", "text": "<p>I would rather not use the term feed.</p>", "time": "2023-07-24T18:12:37Z"}, {"author": "Michael Prorock", "text": "<p>bikeshed time again</p>", "time": "2023-07-24T18:14:57Z"}, {"author": "Raymond Lutz", "text": "<p>lol yes, but it is bc it gives people the wrong idea. At this level, we can push the decisions up to upper level of abstraction but eventually need to be dealt with.</p>", "time": "2023-07-24T18:18:13Z"}, {"author": "Leif Johansson", "text": "<p>.well-known is for discovery, the REST is the API</p>", "time": "2023-07-24T18:18:23Z"}, {"author": "Dick Brooks", "text": "<p>Here is the URL to the trusted SCITT registered VRF from the Hackathon: <a href=\"https://app.rkvst.io/_api/archivist/v2/attachments/publicassets/517b02c0-1274-40d6-a85d-fe402aa8275e/384d1461-6e2c-4a8b-9abd-f9eb14b6c89c\">https://app.rkvst.io/_api/archivist/v2/attachments/publicassets/517b02c0-1274-40d6-a85d-fe402aa8275e/384d1461-6e2c-4a8b-9abd-f9eb14b6c89c</a></p>", "time": "2023-07-24T18:19:30Z"}, {"author": "Eliot Lear", "text": "<p>That is a perfectly valid URL; and so long as you don't want to standardize its structure, there's no issue.</p>", "time": "2023-07-24T18:21:55Z"}, {"author": "Eliot Lear", "text": "<p>Once you want to standardize the structure, that's where you need to consider rfc 8820</p>", "time": "2023-07-24T18:22:44Z"}, {"author": "Michael Prorock", "text": "<p>+1 bob - especially bc the classes may each have different regulatory requirements that may be contradictory</p>", "time": "2023-07-24T18:24:14Z"}, {"author": "Dick Brooks", "text": "<p>Good point Eliot. This needs more discussion. Should all SCITT registries return a \"common syntax\" URL to a registered artifact. IDK - need to noodle on this.</p>", "time": "2023-07-24T18:24:43Z"}, {"author": "Dick Brooks", "text": "<p>We all love our babies <span aria-label=\"wink\" class=\"emoji emoji-1f609\" role=\"img\" title=\"wink\">:wink:</span></p>", "time": "2023-07-24T18:25:40Z"}, {"author": "David Waltermire", "text": "<p>+1 to the idea of using classes for identity types.</p>", "time": "2023-07-24T18:25:46Z"}, {"author": "Mike Ounsworth", "text": "<p>... just start a \"SCITT Security Considerations\" draft and punt into that all the discussion about ways these building blocks could be abused?</p>", "time": "2023-07-24T18:27:38Z"}, {"author": "Dick Brooks", "text": "<p>+1 Orie</p>", "time": "2023-07-24T18:28:48Z"}, {"author": "Raymond Lutz", "text": "<p>current proposal of scitt provides sufficient flexibility in my view to support various solutions at higher levels of abstraction. I support completing this level and deferring those issues for later.</p>", "time": "2023-07-24T18:29:00Z"}, {"author": "Dick Brooks", "text": "<p>SCITT doesn't validate the content submitted, just like a Registry of Deeds</p>", "time": "2023-07-24T18:29:34Z"}, {"author": "Dick Brooks", "text": "<p>Excellent job, guys/</p>", "time": "2023-07-24T18:29:57Z"}, {"author": "Raymond Lutz", "text": "<p>thank you good meeting.</p>", "time": "2023-07-24T18:30:00Z"}, {"author": "Raymond Lutz", "text": "<p>Please post follow on meeting to list I would think.</p>", "time": "2023-07-24T18:30:24Z"}]