Skip to content

Commit b0109be

Browse files
author
ID Bot
committed
Script updating archive at 2024-10-01T00:52:16Z. [ci skip]
1 parent c5ec586 commit b0109be

File tree

1 file changed

+167
-11
lines changed

1 file changed

+167
-11
lines changed

‎archive.json

Lines changed: 167 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2024-09-29T00:51:12.895642+00:00",
3+
"timestamp": "2024-10-01T00:51:55.074343+00:00",
44
"repo": "ietf-wg-scitt/draft-ietf-scitt-architecture",
55
"labels": [
66
{
@@ -5077,9 +5077,9 @@
50775077
"labels": [
50785078
"ready-for-pr"
50795079
],
5080-
"body": "> Signed Certificate Timestamps are checked by Relying Parties\r\n\r\nI would argue that in CT Auditors are checking more than Signed Certificate Timestamps",
5080+
"body": "> [Signed Certificate Timestamps are checked by Relying Parties](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/blob/268-figure-1-description/draft-ietf-scitt-architecture.md?plain=1#L319)\r\n\r\nI would argue that in CT Auditors are checking more than Signed Certificate Timestamps\r\n",
50815081
"createdAt": "2024-07-20T17:29:27Z",
5082-
"updatedAt": "2024-08-07T04:43:08Z",
5082+
"updatedAt": "2024-09-30T23:40:34Z",
50835083
"closedAt": null,
50845084
"comments": [
50855085
{
@@ -5088,6 +5088,13 @@
50885088
"body": "@hannestschofenig there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/301. I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)",
50895089
"createdAt": "2024-08-07T04:43:07Z",
50905090
"updatedAt": "2024-08-07T04:43:07Z"
5091+
},
5092+
{
5093+
"author": "SteveLasker",
5094+
"authorAssociation": "COLLABORATOR",
5095+
"body": "@hannestschofenig, thanks for the issue. \r\nDid you have an intent for what to scope? Reading the [current content of this section](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/blob/268-figure-1-description/draft-ietf-scitt-architecture.md?plain=1#L313), it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported.\r\n\r\n> SCITT is a generalization of Certificate Transparency (CT) {{-CT}}, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.\r\nConsidering CT in terms of SCITT:\r\n>\r\n> - CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements)\r\n> - CAs submit the certificates to one or more CT logs (Transparency Services)\r\n> - CT logs produce Signed Certificate Timestamps (Transparent Statements)\r\n> - Signed Certificate Timestamps are checked by Relying Parties\r\n> - The Append-only Log can be checked by Auditors\r\n\r\nI'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.\r\n",
5096+
"createdAt": "2024-09-30T23:40:33Z",
5097+
"updatedAt": "2024-09-30T23:40:33Z"
50915098
}
50925099
]
50935100
},
@@ -5164,10 +5171,12 @@
51645171
"author": "hannestschofenig",
51655172
"authorAssociation": "COLLABORATOR",
51665173
"assignees": [],
5167-
"labels": [],
5168-
"body": "> Transparency Services MUST also maintain a list of trust anchors,\r\n which SHOULD be used by Relying Parties to authenticate Issuers, and\r\n which MAY be included in a Registration Policy statement.\r\n\r\nI don't understand the SHOULD.\r\n\r\nYou have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.",
5174+
"labels": [
5175+
"has-pr"
5176+
],
5177+
"body": "_Editors note: updated with a link to the referenced text:_ \r\n\r\n> [Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/blob/268-figure-1-description/draft-ietf-scitt-architecture.md?plain=1#L407)\r\n\r\nI don't understand the SHOULD.\r\n\r\nYou have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.",
51695178
"createdAt": "2024-07-20T17:48:13Z",
5170-
"updatedAt": "2024-07-21T17:21:22Z",
5179+
"updatedAt": "2024-10-01T00:09:29Z",
51715180
"closedAt": null,
51725181
"comments": [
51735182
{
@@ -5183,6 +5192,13 @@
51835192
"body": "It's not the use of the anchor in verifying that is optional. It is the use of issuer verification as a gate to registration that is the problem. \r\n\r\nFor ts implementations that naturaly have RBAC at the edge, the \"spam\" problem is not really a problem.\r\n\r\nStatements about statements seem to me to be a better way to deal with use cases where strong issuer verification is necessary. Registration time checks can only ever be \"point in time\"",
51845193
"createdAt": "2024-07-21T17:21:21Z",
51855194
"updatedAt": "2024-07-21T17:21:21Z"
5195+
},
5196+
{
5197+
"author": "SteveLasker",
5198+
"authorAssociation": "COLLABORATOR",
5199+
"body": "My read of the Issue and the current state of the document is:\r\n\r\n- This section is under [Registration Policies](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/blob/268-figure-1-description/draft-ietf-scitt-architecture.md?plain=1#L401), which implies the MUST refers to enabling the registration process. Currently, a registration can not be completed unless the issuer is verified, which can't occur without trust anchors.\r\nThe SHOULD refers to verifiers which are not part of the Registration Policy. I think their inclusion in this section is confusing. \r\n\r\nSee #304 for a proposal.",
5200+
"createdAt": "2024-10-01T00:09:22Z",
5201+
"updatedAt": "2024-10-01T00:09:22Z"
51865202
}
51875203
]
51885204
},
@@ -5387,11 +5403,12 @@
53875403
"roywill"
53885404
],
53895405
"labels": [
5406+
"pending-close",
53905407
"ready-for-pr"
53915408
],
53925409
"body": "> All contents exchanged between actors is protected using secure authenticated channels (e.g., TLS) but may not exclude network traffic analysis.\r\n\r\nThis sentence in the security consideration section gives the reader the impression that communication security is assumed to be used. This is, however, not even discussed in the body of the document.",
53935410
"createdAt": "2024-07-20T19:35:46Z",
5394-
"updatedAt": "2024-08-07T04:24:26Z",
5411+
"updatedAt": "2024-09-30T23:31:04Z",
53955412
"closedAt": null,
53965413
"comments": [
53975414
{
@@ -5428,6 +5445,13 @@
54285445
"body": "> I think a deeper issue is that it's not clear that an authenticated channel _is_ actually required in most cases.\r\n\r\nI was going to counter with some whataboutism and say \"what about RFC9162!?\" but it seems you are right. In the Security Considerations and elsewhere they never really explicate that, so your point stands.\r\n\r\nI guess I would be interested in how this \"frees up\" TS instances conformant to the architecture that do not strictly use HTTPS and TLS a la SCRAPI, but that is outside the scope of this document and SCRAPI too, so I will leave my comment there for now. \ud83d\ude04 ",
54295446
"createdAt": "2024-08-07T04:24:25Z",
54305447
"updatedAt": "2024-08-07T04:24:25Z"
5448+
},
5449+
{
5450+
"author": "SteveLasker",
5451+
"authorAssociation": "COLLABORATOR",
5452+
"body": "Proposing we close, and leave TLS to be API specific (aka SCRAPI)\r\n\r\nIf no objections, or more specifically no PRs are submitted by Oct 8, 2024, I propose we close this issue.",
5453+
"createdAt": "2024-09-30T23:30:57Z",
5454+
"updatedAt": "2024-09-30T23:30:57Z"
54315455
}
54325456
]
54335457
},
@@ -39594,13 +39618,13 @@
3959439618
"labels": [],
3959539619
"body": "Closes #268.",
3959639620
"createdAt": "2024-08-07T03:45:51Z",
39597-
"updatedAt": "2024-09-03T23:25:12Z",
39621+
"updatedAt": "2024-09-30T23:16:00Z",
3959839622
"baseRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
3959939623
"baseRefName": "main",
3960039624
"baseRefOid": "87e995196dedf30a8c58508e51b93a9ea9e989fa",
3960139625
"headRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
3960239626
"headRefName": "268-figure-1-description",
39603-
"headRefOid": "eb586401a48bd0ea99543acb938654652c052917",
39627+
"headRefOid": "dad88f9fbc4801d9e7746fdba99d3633a36bccb0",
3960439628
"closedAt": null,
3960539629
"mergedAt": null,
3960639630
"mergedBy": null,
@@ -39669,9 +39693,9 @@
3966939693
"comments": [
3967039694
{
3967139695
"originalPosition": 8,
39672-
"body": "Removed the reference to Transparent Statements as those are assembled on the client\r\n```suggestion\r\n* Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration\r\n```",
39696+
"body": "Removed the reference to Transparent Statements as those are assembled on the client\r\n```suggestion\r\n* Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration.\r\nThe returned Receipt may be combined with the Signed Statement to create a Transparent Statement.\r\n```",
3967339697
"createdAt": "2024-08-13T19:48:35Z",
39674-
"updatedAt": "2024-08-13T19:49:26Z"
39698+
"updatedAt": "2024-09-30T23:18:57Z"
3967539699
}
3967639700
]
3967739701
},
@@ -39759,6 +39783,86 @@
3975939783
"createdAt": "2024-09-03T23:25:12Z",
3976039784
"updatedAt": "2024-09-03T23:25:12Z",
3976139785
"comments": []
39786+
},
39787+
{
39788+
"id": "PRR_kwDOIvmHss6LZr9a",
39789+
"commit": {
39790+
"abbreviatedOid": "eb58640"
39791+
},
39792+
"author": "SteveLasker",
39793+
"authorAssociation": "COLLABORATOR",
39794+
"state": "COMMENTED",
39795+
"body": "",
39796+
"createdAt": "2024-09-30T23:08:07Z",
39797+
"updatedAt": "2024-09-30T23:08:07Z",
39798+
"comments": [
39799+
{
39800+
"originalPosition": 8,
39801+
"body": "Can we get a vote for how to resolve this? \r\nIf the goal is to make the text describe the diagram, the above suggestion hits that mark. \r\nIf we're adding other, valid capabilities, but not reflected in the diagram, we're creating another hole we'll need to patch.",
39802+
"createdAt": "2024-09-30T23:08:07Z",
39803+
"updatedAt": "2024-09-30T23:08:07Z"
39804+
}
39805+
]
39806+
},
39807+
{
39808+
"id": "PRR_kwDOIvmHss6LZtfQ",
39809+
"commit": {
39810+
"abbreviatedOid": "eb58640"
39811+
},
39812+
"author": "SteveLasker",
39813+
"authorAssociation": "COLLABORATOR",
39814+
"state": "COMMENTED",
39815+
"body": "",
39816+
"createdAt": "2024-09-30T23:10:19Z",
39817+
"updatedAt": "2024-09-30T23:10:20Z",
39818+
"comments": [
39819+
{
39820+
"originalPosition": 7,
39821+
"body": "Please review latest suggestion so we can resolve this PR.",
39822+
"createdAt": "2024-09-30T23:10:20Z",
39823+
"updatedAt": "2024-09-30T23:10:20Z"
39824+
}
39825+
]
39826+
},
39827+
{
39828+
"id": "PRR_kwDOIvmHss6LZveX",
39829+
"commit": {
39830+
"abbreviatedOid": "eb58640"
39831+
},
39832+
"author": "SteveLasker",
39833+
"authorAssociation": "COLLABORATOR",
39834+
"state": "COMMENTED",
39835+
"body": "",
39836+
"createdAt": "2024-09-30T23:13:22Z",
39837+
"updatedAt": "2024-09-30T23:13:22Z",
39838+
"comments": [
39839+
{
39840+
"originalPosition": 4,
39841+
"body": "Formatting change, as this sentence should stand alone to introduce the bullets.\r\n```suggestion\r\n{{fig-concept-relationship}} illustrates entities and processes that comprise a Transparency Service independent of any one use case.\r\n\r\n```",
39842+
"createdAt": "2024-09-30T23:13:22Z",
39843+
"updatedAt": "2024-09-30T23:14:50Z"
39844+
}
39845+
]
39846+
},
39847+
{
39848+
"id": "PRR_kwDOIvmHss6LZxdc",
39849+
"commit": {
39850+
"abbreviatedOid": "b5a2c0f"
39851+
},
39852+
"author": "SteveLasker",
39853+
"authorAssociation": "COLLABORATOR",
39854+
"state": "COMMENTED",
39855+
"body": "",
39856+
"createdAt": "2024-09-30T23:15:56Z",
39857+
"updatedAt": "2024-09-30T23:15:56Z",
39858+
"comments": [
39859+
{
39860+
"originalPosition": 10,
39861+
"body": "```suggestion\r\n* Relying Parties that:\r\n```",
39862+
"createdAt": "2024-09-30T23:15:56Z",
39863+
"updatedAt": "2024-09-30T23:15:56Z"
39864+
}
39865+
]
3976239866
}
3976339867
]
3976439868
},
@@ -40078,6 +40182,58 @@
4007840182
]
4007940183
}
4008040184
]
40185+
},
40186+
{
40187+
"number": 304,
40188+
"id": "PR_kwDOIvmHss59L0hu",
40189+
"title": "Trust anchor clarity in registration policies",
40190+
"url": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/304",
40191+
"state": "OPEN",
40192+
"author": "SteveLasker",
40193+
"authorAssociation": "COLLABORATOR",
40194+
"assignees": [],
40195+
"labels": [],
40196+
"body": "Fixes #270 ",
40197+
"createdAt": "2024-10-01T00:08:38Z",
40198+
"updatedAt": "2024-10-01T00:08:39Z",
40199+
"baseRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
40200+
"baseRefName": "main",
40201+
"baseRefOid": "7615e71467cb9cf8cd7ffbb19048e3eda6f1f3c2",
40202+
"headRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
40203+
"headRefName": "steve/resolves-270",
40204+
"headRefOid": "6bb7789cd4cdd0df5e369fbb8759d0e6c009d88e",
40205+
"closedAt": null,
40206+
"mergedAt": null,
40207+
"mergedBy": null,
40208+
"mergeCommit": null,
40209+
"comments": [],
40210+
"reviews": []
40211+
},
40212+
{
40213+
"number": 305,
40214+
"id": "PR_kwDOIvmHss59L9GC",
40215+
"title": "Add clarity for lines and duplicate boxes",
40216+
"url": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/305",
40217+
"state": "OPEN",
40218+
"author": "SteveLasker",
40219+
"authorAssociation": "COLLABORATOR",
40220+
"assignees": [],
40221+
"labels": [],
40222+
"body": "Note: This PR assumes #300 is merged, and may need to be updated to fit within the context of #300's final text. \r\n\r\nFixes #268 \r\n\r\n",
40223+
"createdAt": "2024-10-01T00:50:24Z",
40224+
"updatedAt": "2024-10-01T00:50:24Z",
40225+
"baseRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
40226+
"baseRefName": "main",
40227+
"baseRefOid": "7615e71467cb9cf8cd7ffbb19048e3eda6f1f3c2",
40228+
"headRepository": "ietf-wg-scitt/draft-ietf-scitt-architecture",
40229+
"headRefName": "steve/268",
40230+
"headRefOid": "ebeb62bc229514b1f103472e8c874d39d00a0039",
40231+
"closedAt": null,
40232+
"mergedAt": null,
40233+
"mergedBy": null,
40234+
"mergeCommit": null,
40235+
"comments": [],
40236+
"reviews": []
4008140237
}
4008240238
]
4008340239
}

0 commit comments

Comments
 (0)