Script updating archive at 2023-09-05T00:32:27Z. [ci skip]

ietf-wg-scitt · Sep 5, 2023 · 3b43999 · 3b43999
1 parent 0662a75
commit 3b43999
Showing 1 changed file with 57 additions and 13 deletions.
diff --git a/archive.json b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2023-09-03T00:34:46.693498+00:00",
+  "timestamp": "2023-09-05T00:32:23.700944+00:00",
   "repo": "ietf-wg-scitt/draft-ietf-scitt-architecture",
   "labels": [
     {
@@ -1390,15 +1390,15 @@
       "id": "I_kwDOIvmHss5gc4m8",
       "title": "Document rationale for COSE vs DSSE etc.",
       "url": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/57",
-      "state": "OPEN",
+      "state": "CLOSED",
       "author": "nealmcb",
       "authorAssociation": "NONE",
       "assignees": [],
       "labels": [],
       "body": "Re: #40:\r\n\r\nThe [SCITT charter](https://datatracker.ietf.org/wg/scitt/about/) says:\r\n> reuse existing work from IETF WGs such as COSE and RATS, as appropriate,\r\n\r\nThe words \"as appropriate\" suggest to me that we should have some discussion of the pros and cons of mandating COSE, and address alternatives.\r\n\r\nIn particular, there is already deployment experience with the closely-related effort [Sigstore](https://www.sigstore.dev/) which uses [DSSE: Dead Simple Signing Envelope](https://github.com/secure-systems-lab/dsse). Some googling will surface a comparison of [Signature Formats. Envelopes and Wrappers and Formats, Oh My! by Dan Lorenc](https://dlorenc.medium.com/signature-formats-9b7b2a127473) which recommends DSSE over the family of JOSE standards, which includes COSE to some extent, though COSE is not covered in that article.\r\n\r\nI think we'd should try to promote interoperability with Sigstore.\r\n\r\nIs there some background info somewhere on advantages of mandating COSE?",
       "createdAt": "2023-03-10T00:41:23Z",
-      "updatedAt": "2023-03-29T07:18:30Z",
-      "closedAt": null,
+      "updatedAt": "2023-09-04T20:59:20Z",
+      "closedAt": "2023-09-04T15:20:15Z",
       "comments": [
         {
           "author": "SteveLasker",
@@ -1427,6 +1427,20 @@
           "body": "Building on IETF standards ensures widely available tooling and an expert community that can provide reviews, and support for profiles and extensions.\r\n\r\nThere is also an IETF procedural detail on citing envelope formats that are not RFCs or of an equivalent maturity level.\r\n\r\nI don't think we should support an envelope format other than COSE. \r\n\r\n",
           "createdAt": "2023-03-29T07:18:29Z",
           "updatedAt": "2023-03-29T07:18:29Z"
+        },
+        {
+          "author": "hannestschofenig",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "Closing the issue since there are not further actions.",
+          "createdAt": "2023-09-04T15:20:15Z",
+          "updatedAt": "2023-09-04T15:20:15Z"
+        },
+        {
+          "author": "nealmcb",
+          "authorAssociation": "NONE",
+          "body": "I appreciate the discussion here to date - it is helpful! And I don't mean to detract from SCITT progress, or question the decision to build on IETF signature format standards\r\n\r\nBut I still see value in getting more clarity on the technical tradeoffs between COSE and DSSE, as the current title of this issue reflects.\r\n\r\nA comment above describes DSSE as \"proprietary\". It may not be under change control of a recognized standards-making body, but it is [licenced via Apache License 2.0](https://github.com/secure-systems-lab/dsse/blob/master/LICENSE) and thus quite open and not proprietary.\r\n\r\nI note that the draft discussion document at [Digital Artifact Signing Envelope Format Comparison](https://docs.google.com/document/d/18YVGA4mq45wfUkWrAqWkymzdHRcXxlwINKXnEp86L0w/) still has lots of unresolved issues.\r\n\r\nI'll also note that I've added a similar comment to DSSE at [Document rationale for DSSE vs COSE etc](https://github.com/secure-systems-lab/dsse/issues/62).\r\n\r\nIn my mind, ideally the discussion document would end up published in a cleaned-up, if not fully agreed-upon form.\r\n\r\nIf nothing else, perhaps future web searches will more easily surface one of these documents, leading to useful insights.\r\n\r\nIf there is any hope that some folks may continue to engage on those fronts, I'd request that this issue be reopened, to help encourage that.",
+          "createdAt": "2023-09-04T20:59:19Z",
+          "updatedAt": "2023-09-04T20:59:19Z"
         }
       ]
     },
@@ -1896,11 +1910,13 @@
       "state": "OPEN",
       "author": "hannestschofenig",
       "authorAssociation": "CONTRIBUTOR",
-      "assignees": [],
+      "assignees": [
+        "OR13"
+      ],
       "labels": [],
       "body": "The formatting of that section is a nightmare. It makes me wonder whether it makes more sense to just illustrate an incomplete example. For example:\r\n\r\n```\r\n{\r\n   \"keys\":[\r\n      {\r\n         \"alg\":\"RS256\",\r\n         \"kty\":\"RSA\",\r\n         \"use\":\"sig\",\r\n         \"n\":\"wW9...4zw\",\r\n         \"e\":\"AQAB\",\r\n         \"kid\":\"NTBG..U5OA\",\r\n         \"x5t\":\"NTBG..U5OA\",\r\n         \"x5c\":[\r\n            \"MII...g3R+\"\r\n         ]\r\n      },\r\n      {\r\n         \"alg\":\"RS256\",\r\n         \"kty\":\"RSA\",\r\n         \"use\":\"sig\",\r\n         \"n\":\"ylg...DWw\",\r\n         \"e\":\"AQAB\",\r\n         \"kid\":\"aMI...9ln\",\r\n         \"x5t\":\"-xcT...Tbs\",\r\n         \"x5c\":[\r\n            \"MII...FZdA==\"\r\n         ]\r\n      }\r\n   ]\r\n}\r\n```",
       "createdAt": "2023-08-14T13:07:41Z",
-      "updatedAt": "2023-08-14T13:08:23Z",
+      "updatedAt": "2023-09-04T15:02:00Z",
       "closedAt": null,
       "comments": []
     },
@@ -1916,9 +1932,17 @@
       "labels": [],
       "body": "Section 6.1 describes the CDDL of the signed statement and calls it envelope. Why don't you call it signed statement?",
       "createdAt": "2023-08-14T13:11:14Z",
-      "updatedAt": "2023-08-14T13:11:14Z",
+      "updatedAt": "2023-09-04T15:01:44Z",
       "closedAt": null,
-      "comments": []
+      "comments": [
+        {
+          "author": "hannestschofenig",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "Fixed this in https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/94",
+          "createdAt": "2023-09-04T15:01:43Z",
+          "updatedAt": "2023-09-04T15:01:43Z"
+        }
+      ]
     }
   ],
   "pulls": [
@@ -8624,15 +8648,15 @@
       "authorAssociation": "CONTRIBUTOR",
       "assignees": [],
       "labels": [],
-      "body": "This is still work in progress",
+      "body": "Attempt to clean up Section 6",
       "createdAt": "2023-08-14T16:16:43Z",
-      "updatedAt": "2023-08-21T15:17:06Z",
+      "updatedAt": "2023-09-04T15:01:37Z",
       "baseRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
       "baseRefName": "main",
       "baseRefOid": "4e490bbe2c001874f4d1da7265fde8d92f7fffde",
       "headRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
       "headRefName": "hannestschofenig-patch-1",
-      "headRefOid": "78a1a78183c0738c16f603b44a649caa3ee5c049",
+      "headRefOid": "35d970fd0bac09708d46beea7d5b86fc77c304a9",
       "closedAt": null,
       "mergedAt": null,
       "mergedBy": null,
@@ -8773,13 +8797,13 @@
       "labels": [],
       "body": "Fixes #91 ",
       "createdAt": "2023-08-29T13:53:14Z",
-      "updatedAt": "2023-09-01T15:48:32Z",
+      "updatedAt": "2023-09-03T14:28:34Z",
       "baseRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
       "baseRefName": "main",
       "baseRefOid": "0f468f4e36876a94489bf1748b838e52040655d3",
       "headRepository": "ad-l/draft-ietf-scitt-architecture",
       "headRefName": "main",
-      "headRefOid": "a0a7589b35a38c95b9c4201452dd4700f081fb5c",
+      "headRefOid": "c1ce4ad1cb978338c160189763a317dfbb471d2a",
       "closedAt": null,
       "mergedAt": null,
       "mergedBy": null,
@@ -9218,6 +9242,26 @@
               "updatedAt": "2023-09-01T15:48:32Z"
             }
           ]
+        },
+        {
+          "id": "PRR_kwDOIvmHss5f4FBy",
+          "commit": {
+            "abbreviatedOid": "c1ce4ad"
+          },
+          "author": "henkbirkholz",
+          "authorAssociation": "MEMBER",
+          "state": "COMMENTED",
+          "body": "",
+          "createdAt": "2023-09-03T14:28:33Z",
+          "updatedAt": "2023-09-03T14:28:34Z",
+          "comments": [
+            {
+              "originalPosition": 54,
+              "body": "That would be one example. I am not sure, if limiting, for example, to certificate and private signing key is a useful thing to do here. Maybe it is, but it feels rather artificially constraining.\r\n\r\nMaybe this is also a symptom of a bigger problem? \"Identity\" is a hot topic in scitt (as the thread you started shows: https://mailarchive.ietf.org/arch/msg/scitt/kubTlBU7sKLSkTpHdVqudsY7U1Y). Maybe we should dedicate text on that topic (carefully, in order to support to operationalize) based on that discussion and then refer back to a corresponding section?",
+              "createdAt": "2023-09-03T14:28:33Z",
+              "updatedAt": "2023-09-03T14:28:34Z"
+            }
+          ]
         }
       ]
     }