Skip to content

Commit 77c53bc

Browse files
author
ID Bot
committed
Script updating archive at 2025-11-13T02:06:36Z. [ci skip]
1 parent f8917fa commit 77c53bc

1 file changed

Lines changed: 159 additions & 3 deletions

File tree

‎archive.json‎

Lines changed: 159 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2025-11-09T02:07:58.322045+00:00",
3+
"timestamp": "2025-11-13T02:06:33.454965+00:00",
44
"repo": "davidben/merkle-tree-certs",
55
"labels": [
66
{
@@ -2611,6 +2611,44 @@
26112611
"updatedAt": "2025-10-21T23:31:08Z",
26122612
"closedAt": null,
26132613
"comments": []
2614+
},
2615+
{
2616+
"number": 162,
2617+
"id": "I_kwDOJIBkVc7XOAU2",
2618+
"title": "Duplicate landmarks?",
2619+
"url": "https://github.com/davidben/merkle-tree-certs/issues/162",
2620+
"state": "OPEN",
2621+
"author": "bwesterb",
2622+
"authorAssociation": "COLLABORATOR",
2623+
"assignees": [],
2624+
"labels": [],
2625+
"body": "If we want to keep a regular cadence of landmarks, then we need to be able to issue duplicate landmarks if the MTCA didn't issue for that period. Currently, the section on landmarks doesn't prohibit this (there is no \"strictly\" in front of \"monotonically increasing\".) However, the text on how to assign subtrees to landmarks tacitly assumes they're not empty.\n\nI see two options:\n\n- Explicitly allow duplicate landmarks, and change text accordingly (eg. no subtrees are associated to them.)\n- Be explicit that landmark issuance can be stalled when no new certificates were issued.\n\nThe advantage of the latter is that it's simpler. The downside is that it's not directly obvious which landmarks are useless because all certificates in them expired. The advantage of allowing duplicate landmarks, is that it naturally leaves out the useless tree heads that expired.",
2626+
"createdAt": "2025-11-11T05:31:47Z",
2627+
"updatedAt": "2025-11-11T06:10:28Z",
2628+
"closedAt": null,
2629+
"comments": [
2630+
{
2631+
"author": "davidben",
2632+
"authorAssociation": "OWNER",
2633+
"body": "The latter is what I had in mind. I think I'd just forgotten that \"monotonically increasing\" and \"strictly monotonically increasing\" were different things. \ud83d\ude06 It does mean that you might have some landmarks with expired certificates, but that's always true. It was only ever an upper bound:\n* Maybe the CA set tighter notAfter than it needed\n* Maybe we're right before the next allocation and 99% of the last landmark is expired already\n\nBut also saying that duplication landmarks just contribute zero subtrees is also easy enough, if we prefer that. \ud83e\udd37",
2634+
"createdAt": "2025-11-11T05:36:23Z",
2635+
"updatedAt": "2025-11-11T05:36:23Z"
2636+
},
2637+
{
2638+
"author": "bwesterb",
2639+
"authorAssociation": "COLLABORATOR",
2640+
"body": "> I think I'd just forgotten that \"monotonically increasing\" and \"strictly monotonically increasing\" were different things.\n\nTotal tangent: is zero a positive number? In the past it was common to read *increasing* strictly, and they would use non-decreasing for the non-strict version like non-negative to include zero.\n\n> But also saying that duplication landmarks just contribute zero subtrees is also easy enough, if we prefer that. \ud83e\udd37\n\nLet's stick with what we have now, and revisit if slow issuing MTCAs turn out to be a thing.\n\nUpdate: clarified in https://github.com/davidben/merkle-tree-certs/commit/494e27f920efcc4dff5fcb6cb0311b95ac8396bf",
2641+
"createdAt": "2025-11-11T05:42:02Z",
2642+
"updatedAt": "2025-11-11T05:46:26Z"
2643+
},
2644+
{
2645+
"author": "davidben",
2646+
"authorAssociation": "OWNER",
2647+
"body": "Added another missing one in 27312f81241a32bdbd72bc9db8650e214f03316c",
2648+
"createdAt": "2025-11-11T06:10:27Z",
2649+
"updatedAt": "2025-11-11T06:10:27Z"
2650+
}
2651+
]
26142652
}
26152653
],
26162654
"pulls": [
@@ -9729,13 +9767,13 @@
97299767
"labels": [],
97309768
"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.",
97319769
"createdAt": "2025-11-06T22:27:21Z",
9732-
"updatedAt": "2025-11-07T13:10:23Z",
9770+
"updatedAt": "2025-11-11T20:38:48Z",
97339771
"baseRepository": "davidben/merkle-tree-certs",
97349772
"baseRefName": "main",
97359773
"baseRefOid": "ec6bdf99df5d03f40fec460dbd664bc84f749b6f",
97369774
"headRepository": "davidben/merkle-tree-certs",
97379775
"headRefName": "tai-alias",
9738-
"headRefOid": "1a9b5f9d06728ec17dcc5b51c79fb56073d3a271",
9776+
"headRefOid": "86af2bd12b4d3964c1e27f1f842fdc23e60764a1",
97399777
"closedAt": null,
97409778
"mergedAt": null,
97419779
"mergedBy": null,
@@ -9867,6 +9905,124 @@
98679905
"updatedAt": "2025-11-07T13:10:24Z"
98689906
}
98699907
]
9908+
},
9909+
{
9910+
"id": "PRR_kwDOJIBkVc7NnvYy",
9911+
"commit": {
9912+
"abbreviatedOid": "1a9b5f9"
9913+
},
9914+
"author": "bwesterb",
9915+
"authorAssociation": "COLLABORATOR",
9916+
"state": "COMMENTED",
9917+
"body": "",
9918+
"createdAt": "2025-11-11T19:52:10Z",
9919+
"updatedAt": "2025-11-11T19:52:10Z",
9920+
"comments": [
9921+
{
9922+
"originalPosition": 49,
9923+
"body": "Whoops, correction: In step 2, `v` can be `2^57-1`. Thus in step 3, `v` can be `2^64 - 127 + 127`, which is larger than 2^64-1. ",
9924+
"createdAt": "2025-11-11T19:52:10Z",
9925+
"updatedAt": "2025-11-11T19:52:10Z"
9926+
}
9927+
]
9928+
},
9929+
{
9930+
"id": "PRR_kwDOJIBkVc7NkM9e",
9931+
"commit": {
9932+
"abbreviatedOid": "86af2bd"
9933+
},
9934+
"author": "davidben",
9935+
"authorAssociation": "OWNER",
9936+
"state": "COMMENTED",
9937+
"body": "> Should there be something said about how the DNS negotiation & the retry mechanism work with ranges?\r\n\r\nDone\r\n\r\n> Since 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\r\nAgreed. Tried to clarify this in the new text.",
9938+
"createdAt": "2025-11-11T16:08:34Z",
9939+
"updatedAt": "2025-11-11T20:38:48Z",
9940+
"comments": [
9941+
{
9942+
"originalPosition": 45,
9943+
"body": "Apparently it works, amazingly. `<sup>` is one of the tags in the RFC XML syntax, and it actually renders as `2^64` in the text form.",
9944+
"createdAt": "2025-11-11T16:08:35Z",
9945+
"updatedAt": "2025-11-11T20:38:48Z"
9946+
},
9947+
{
9948+
"originalPosition": 47,
9949+
"body": "Ah good idea. Done.",
9950+
"createdAt": "2025-11-11T16:25:40Z",
9951+
"updatedAt": "2025-11-11T20:38:48Z"
9952+
},
9953+
{
9954+
"originalPosition": 49,
9955+
"body": "I believe this is fine. `(2^57-1) << 7` is not `2^64-1`. It's `2^64-128`, so 127 slots in nicely.",
9956+
"createdAt": "2025-11-11T16:26:57Z",
9957+
"updatedAt": "2025-11-11T20:38:48Z"
9958+
},
9959+
{
9960+
"originalPosition": 54,
9961+
"body": "Done.",
9962+
"createdAt": "2025-11-11T16:27:18Z",
9963+
"updatedAt": "2025-11-11T20:38:48Z"
9964+
},
9965+
{
9966+
"originalPosition": 61,
9967+
"body": "Yeah, at least right now we're just negotiating log IDs and the cosigner IDs don't really do much. I'd really like to do cosigner negotiation, but we'll have to get to that. :-)",
9968+
"createdAt": "2025-11-11T16:28:17Z",
9969+
"updatedAt": "2025-11-11T20:38:48Z"
9970+
},
9971+
{
9972+
"originalPosition": 69,
9973+
"body": "Just so there's something to fit into the DNS and EE bits.",
9974+
"createdAt": "2025-11-11T16:37:31Z",
9975+
"updatedAt": "2025-11-11T20:38:48Z"
9976+
},
9977+
{
9978+
"originalPosition": 18,
9979+
"body": "Done",
9980+
"createdAt": "2025-11-11T17:37:56Z",
9981+
"updatedAt": "2025-11-11T20:38:48Z"
9982+
},
9983+
{
9984+
"originalPosition": 36,
9985+
"body": "Done",
9986+
"createdAt": "2025-11-11T17:38:12Z",
9987+
"updatedAt": "2025-11-11T20:38:48Z"
9988+
},
9989+
{
9990+
"originalPosition": 36,
9991+
"body": "Reworded slightly.",
9992+
"createdAt": "2025-11-11T17:38:43Z",
9993+
"updatedAt": "2025-11-11T20:38:48Z"
9994+
},
9995+
{
9996+
"originalPosition": 39,
9997+
"body": "Done",
9998+
"createdAt": "2025-11-11T19:22:32Z",
9999+
"updatedAt": "2025-11-11T20:38:48Z"
10000+
},
10001+
{
10002+
"originalPosition": 38,
10003+
"body": "Done",
10004+
"createdAt": "2025-11-11T19:23:39Z",
10005+
"updatedAt": "2025-11-11T20:38:48Z"
10006+
},
10007+
{
10008+
"originalPosition": 69,
10009+
"body": "I think that's correct? If `max_landmarks` is 1, then the client keeps track of one landmark at a time, which means the only landmark that matches is `L`.\r\n\r\nStrictly speaking, this is all irrelevant. We can just set `max` to 2<sup>64</sup>-1 and not think about it very hard. The expired ones will fall off anyway.\r\n\r\n(I turned `L+1` to `L` so we don't produce an invalid range, but this is redundant with the exact match.)",
10010+
"createdAt": "2025-11-11T19:27:12Z",
10011+
"updatedAt": "2025-11-11T20:38:48Z"
10012+
},
10013+
{
10014+
"originalPosition": 72,
10015+
"body": "It seemed worth making it clear that we're negotiating based on the thing that derives the subtrees, not the subtrees.",
10016+
"createdAt": "2025-11-11T19:28:12Z",
10017+
"updatedAt": "2025-11-11T20:38:48Z"
10018+
},
10019+
{
10020+
"originalPosition": 72,
10021+
"body": "...I could have sworn \"don't send the expired ones\" was already implicitly in TAI, but maybe that was lost when going from trust expressions to trust anchor IDs. I think expiry should be part of the general framework because it's a general problem.\r\n\r\n(It's *already* the case that you might trust a subtree but some certificates in the subtree are expired.)",
10022+
"createdAt": "2025-11-11T19:30:13Z",
10023+
"updatedAt": "2025-11-11T20:38:48Z"
10024+
}
10025+
]
987010026
}
987110027
]
987210028
}

0 commit comments

Comments
 (0)