Skip to content

Commit 4c48ef8

Browse files
author
ID Bot
committed
Script updating archive at 2025-11-09T02:08:00Z. [ci skip]
1 parent df311b0 commit 4c48ef8

1 file changed

Lines changed: 196 additions & 3 deletions

File tree

‎archive.json‎

Lines changed: 196 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2025-11-06T02:04:43.880737+00:00",
3+
"timestamp": "2025-11-09T02:07:58.322045+00:00",
44
"repo": "davidben/merkle-tree-certs",
55
"labels": [
66
{
@@ -9622,13 +9622,13 @@
96229622
],
96239623
"body": "",
96249624
"createdAt": "2025-11-05T16:54:37Z",
9625-
"updatedAt": "2025-11-05T17:43:54Z",
9625+
"updatedAt": "2025-11-07T07:37:17Z",
96269626
"baseRepository": "davidben/merkle-tree-certs",
96279627
"baseRefName": "main",
96289628
"baseRefOid": "2f1c8dd7b504ece7c32392583ada020a126f56f0",
96299629
"headRepository": "davidben/merkle-tree-certs",
96309630
"headRefName": "bas/delivery",
9631-
"headRefOid": "dad323141159913b430be63c79aa636ee1f5373f",
9631+
"headRefOid": "303d2b008514a295cf751dc9c65f4e0479e3f360",
96329632
"closedAt": null,
96339633
"mergedAt": null,
96349634
"mergedBy": null,
@@ -9674,6 +9674,199 @@
96749674
"updatedAt": "2025-11-05T17:43:54Z"
96759675
}
96769676
]
9677+
},
9678+
{
9679+
"id": "PRR_kwDOJIBkVc7MMbHN",
9680+
"commit": {
9681+
"abbreviatedOid": "dad3231"
9682+
},
9683+
"author": "davidben",
9684+
"authorAssociation": "OWNER",
9685+
"state": "COMMENTED",
9686+
"body": "",
9687+
"createdAt": "2025-11-06T03:55:50Z",
9688+
"updatedAt": "2025-11-06T03:55:50Z",
9689+
"comments": [
9690+
{
9691+
"originalPosition": 5,
9692+
"body": "It's unclear to me how the WG would meet this. If we only write it for ACME, have we met the charter? If we do it for ACME and Protocol A but not Protocol B, have we?",
9693+
"createdAt": "2025-11-06T03:55:50Z",
9694+
"updatedAt": "2025-11-06T03:55:50Z"
9695+
}
9696+
]
9697+
},
9698+
{
9699+
"id": "PRR_kwDOJIBkVc7MXX6w",
9700+
"commit": {
9701+
"abbreviatedOid": "dad3231"
9702+
},
9703+
"author": "tfpauly",
9704+
"authorAssociation": "NONE",
9705+
"state": "COMMENTED",
9706+
"body": "",
9707+
"createdAt": "2025-11-06T15:04:10Z",
9708+
"updatedAt": "2025-11-06T15:04:11Z",
9709+
"comments": [
9710+
{
9711+
"originalPosition": 5,
9712+
"body": "I'd suggest something like:\r\n```suggestion\r\n3. How the certificate constructions may be provisioned (with mechanisms including ACME (RFC 8555)) and used in TLS.\r\n```",
9713+
"createdAt": "2025-11-06T15:04:10Z",
9714+
"updatedAt": "2025-11-06T15:04:11Z"
9715+
}
9716+
]
9717+
}
9718+
]
9719+
},
9720+
{
9721+
"number": 161,
9722+
"id": "PR_kwDOJIBkVc6yAjzY",
9723+
"title": "Restore the more efficient trust anchor negotiation",
9724+
"url": "https://github.com/davidben/merkle-tree-certs/pull/161",
9725+
"state": "OPEN",
9726+
"author": "davidben",
9727+
"authorAssociation": "OWNER",
9728+
"assignees": [],
9729+
"labels": [],
9730+
"body": "When trust_anchors was extracted from the first MTC drafts, we lost an optimization because it was not, at the time, relevant for the baseline version of the problem. However, it is still quite useful for MTCs (and may be useful for other scenarios too).\r\n\r\nThis implements https://github.com/tlswg/tls-trust-anchor-ids/issues/62 to put it back. For now, it's in the MTC repo, but in the long run, we should put it back in TAI itself.",
9731+
"createdAt": "2025-11-06T22:27:21Z",
9732+
"updatedAt": "2025-11-07T13:10:23Z",
9733+
"baseRepository": "davidben/merkle-tree-certs",
9734+
"baseRefName": "main",
9735+
"baseRefOid": "ec6bdf99df5d03f40fec460dbd664bc84f749b6f",
9736+
"headRepository": "davidben/merkle-tree-certs",
9737+
"headRefName": "tai-alias",
9738+
"headRefOid": "1a9b5f9d06728ec17dcc5b51c79fb56073d3a271",
9739+
"closedAt": null,
9740+
"mergedAt": null,
9741+
"mergedBy": null,
9742+
"mergeCommit": null,
9743+
"comments": [
9744+
{
9745+
"author": "matt-mueller",
9746+
"authorAssociation": "NONE",
9747+
"body": "Should there be something said about how the DNS negotiation & the retry mechanism work with ranges?\r\n\r\nSince the DNS hint could be stale, the client would probably want to match the prefix against its known base_ids, but send the base_id.max for highest chance of success without requiring a round trip. For the retry mechanism the client could do a specific match, but for simplicity it would be nice to just have the client do the same thing in both cases.\r\n",
9748+
"createdAt": "2025-11-07T00:24:37Z",
9749+
"updatedAt": "2025-11-07T00:24:37Z"
9750+
}
9751+
],
9752+
"reviews": [
9753+
{
9754+
"id": "PRR_kwDOJIBkVc7MkrvE",
9755+
"commit": {
9756+
"abbreviatedOid": "1a9b5f9"
9757+
},
9758+
"author": "bwesterb",
9759+
"authorAssociation": "COLLABORATOR",
9760+
"state": "APPROVED",
9761+
"body": "",
9762+
"createdAt": "2025-11-07T08:10:28Z",
9763+
"updatedAt": "2025-11-07T09:05:02Z",
9764+
"comments": [
9765+
{
9766+
"originalPosition": 18,
9767+
"body": "> any relying party which recognizes some landmark is known to additionally accept earlier landmarks, up to the `max_landmarks` parameter.\r\n\r\nNit: by induction a relying will then accept all previous landmarks if *up to* isn't read as a bound.\r\n\r\nWhat about:\r\n\r\n> For example, in this document, the relying party will recognize up to `max_landmark` consecutive landmarks.",
9768+
"createdAt": "2025-11-07T08:10:28Z",
9769+
"updatedAt": "2025-11-07T09:05:02Z"
9770+
},
9771+
{
9772+
"originalPosition": 36,
9773+
"body": "Add \"inclusive\".",
9774+
"createdAt": "2025-11-07T08:13:14Z",
9775+
"updatedAt": "2025-11-07T09:05:02Z"
9776+
},
9777+
{
9778+
"originalPosition": 38,
9779+
"body": "Perhaps mention that this is to check whether `base` is well formed to begin with.",
9780+
"createdAt": "2025-11-07T08:14:25Z",
9781+
"updatedAt": "2025-11-07T09:05:02Z"
9782+
},
9783+
{
9784+
"originalPosition": 39,
9785+
"body": "Suggestion: \"with the prefix r.base removed\"",
9786+
"createdAt": "2025-11-07T08:15:15Z",
9787+
"updatedAt": "2025-11-07T09:05:02Z"
9788+
},
9789+
{
9790+
"originalPosition": 47,
9791+
"body": "This might be read as that the MSB should've been set. We can say \"Unset the MSB (if set)\", or we can just use `(b & 127)` below",
9792+
"createdAt": "2025-11-07T08:21:20Z",
9793+
"updatedAt": "2025-11-07T09:05:02Z"
9794+
},
9795+
{
9796+
"originalPosition": 49,
9797+
"body": "In step 2, `v` can be `2^57-1`. Thus in step 3, `v` can be `2^64 - 1 + 127`, which is larger than 2^64. We can limit to 2^56 in step 2, if we don't care about such that one bit, or we add a step 2b, where we check that `2^64 - b > v<<7`.\r\n\r\n",
9798+
"createdAt": "2025-11-07T08:26:47Z",
9799+
"updatedAt": "2025-11-07T09:05:02Z"
9800+
},
9801+
{
9802+
"originalPosition": 54,
9803+
"body": "It's superfluous, but maybe end this sentence with \"or\".",
9804+
"createdAt": "2025-11-07T08:29:27Z",
9805+
"updatedAt": "2025-11-07T09:05:02Z"
9806+
},
9807+
{
9808+
"originalPosition": 61,
9809+
"body": "To double check: we're not using the ID of the CA's own cosigner.",
9810+
"createdAt": "2025-11-07T08:33:12Z",
9811+
"updatedAt": "2025-11-07T09:05:02Z"
9812+
},
9813+
{
9814+
"originalPosition": 69,
9815+
"body": "If max_landmarks is 1, then max would be set to L, which seems incorrect.",
9816+
"createdAt": "2025-11-07T08:57:53Z",
9817+
"updatedAt": "2025-11-07T09:05:02Z"
9818+
},
9819+
{
9820+
"originalPosition": 69,
9821+
"body": "What is the reason not to simply use a TA range and forego a single TA?",
9822+
"createdAt": "2025-11-07T08:58:39Z",
9823+
"updatedAt": "2025-11-07T09:05:02Z"
9824+
},
9825+
{
9826+
"originalPosition": 72,
9827+
"body": "Do we need to mention the subtrees here? Can't we say \"a relying party that has been configured with landmarks\"?",
9828+
"createdAt": "2025-11-07T08:59:43Z",
9829+
"updatedAt": "2025-11-07T09:05:02Z"
9830+
},
9831+
{
9832+
"originalPosition": 72,
9833+
"body": "It will be common for servers to configure two signatureless certs. If I read it correctly, we're not telling how to pick between them. It seems sensible to sent the signatureless cert with the most recent landmark, as an older one might be expired.",
9834+
"createdAt": "2025-11-07T09:03:03Z",
9835+
"updatedAt": "2025-11-07T09:05:02Z"
9836+
},
9837+
{
9838+
"originalPosition": 72,
9839+
"body": "Actually, it might be the case that all signatureless certs are expired, and it's better to send the full cert.",
9840+
"createdAt": "2025-11-07T09:04:05Z",
9841+
"updatedAt": "2025-11-07T09:05:02Z"
9842+
}
9843+
]
9844+
},
9845+
{
9846+
"id": "PRR_kwDOJIBkVc7Mqz0h",
9847+
"commit": {
9848+
"abbreviatedOid": "1a9b5f9"
9849+
},
9850+
"author": "cjpatton",
9851+
"authorAssociation": "CONTRIBUTOR",
9852+
"state": "APPROVED",
9853+
"body": "",
9854+
"createdAt": "2025-11-07T12:59:46Z",
9855+
"updatedAt": "2025-11-07T13:10:23Z",
9856+
"comments": [
9857+
{
9858+
"originalPosition": 45,
9859+
"body": "nit: I haven't checked, but I imagine this doesn't render the way you expect in the .txt version of the draft. Perhaps write exponents in Python? Here and below.\n```suggestion\n 5. Set `v` to zero. Throughout this procedure, `v` will be less than `2**64`",
9860+
"createdAt": "2025-11-07T12:59:46Z",
9861+
"updatedAt": "2025-11-07T13:10:23Z"
9862+
},
9863+
{
9864+
"originalPosition": 36,
9865+
"body": "Maybe add a sentence here explaining what the procedure is doing.",
9866+
"createdAt": "2025-11-07T13:01:33Z",
9867+
"updatedAt": "2025-11-07T13:10:24Z"
9868+
}
9869+
]
96779870
}
96789871
]
96799872
}

0 commit comments

Comments
 (0)