You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: archive.json
+227-3Lines changed: 227 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
{
2
2
"magic": "E!vIA5L86J2I",
3
-
"timestamp": "2025-10-05T02:04:48.467714+00:00",
3
+
"timestamp": "2025-10-07T01:54:52.698811+00:00",
4
4
"repo": "davidben/merkle-tree-certs",
5
5
"labels": [
6
6
{
@@ -2550,9 +2550,17 @@
2550
2550
"labels": [],
2551
2551
"body": "When we recast MTC as X.509, we picked up all of X.509's semantics, including the fact that a CA can, at least mechanically, issue non-MTC intermediate certificates. Doing so partially bypasses transparency benefits because only the intermediate is logged, not certificates chaining off of it.\n\nI say partially because the fact that the CA has done so is definitely visible in the log. But if the intermediate is unconstrained, and a PKI is okay with it, then we don't actually know what certificates are valid. But this might vary a lot by PKI:\n\n* Maybe your PKI is okay with transparency stopping at an intermediate, as long as it has name constraints, but it's not okay with intermediates without name constraints.\n\n* Maybe your PKI is the above, but its notion of \"name\" is something other than SANs + name constraints and is looking for a random other X.509 extension\n\n* Maybe you do not want to support this at all and want to forbid all intermediates\n\n* Maybe you're just unabashedly okay with all transparency stopping at any intermediate for... some reason? I can't come up with a reason for this.\n\nIf there's a range of options, one plausible, if a bit unsatisfying, answer is that we solve this by policy. X.509 often forces us down this path, sadly. :-( We say that the MTC mechanism itself has no opinion on this, but that a relying party and root program might (and probably should!) opine on this and say what they do and don't allow.\n\nIn that case, the spec should say something about this and note that you need to pick something. We also need the technical mechanisms to apply that policy.\n\nAt a bare minimum, the technical mechanism is \"monitors can see everything the CA signs and know to look for this\" and \"relying parties will hold the CA responsible for detected violations in trust decisions\". If you see a CA=true certificate in the log, you need to treat it as impacting _every_ name (up to constraints) and monitor it it accordingly.\n\nYou might also want relying party enforcement in code so that, even if it is in there, the relying party won't accept it. For at least the \"this CA should not issue intermediates period\" policy, there is _almost_ a natural mechanism in X.509 already: path length constraints.\n\nBut only _almost_ because X.509 special-cases self-issued certificates everywhere as part of key rollover. Is it worth updating RFC 5280 to knock out the self-issued special case? (Alternatively, the enforcement can just be using some extra mechanism. Relying parties add checks atop RFC 5280 path validation all the time.)",
2552
2552
"createdAt": "2025-09-18T17:26:53Z",
2553
-
"updatedAt": "2025-09-18T17:26:53Z",
2553
+
"updatedAt": "2025-10-06T20:37:18Z",
2554
2554
"closedAt": null,
2555
-
"comments": []
2555
+
"comments": [
2556
+
{
2557
+
"author": "davidben",
2558
+
"authorAssociation": "OWNER",
2559
+
"body": "Places where RFC 5280 special-cases self-issued certificates:\n\n* pathLenConstraint does not count self-issued certificates\n* Name constraints are not applied to SANs in self-issued certificates, unless the certificate is the final one\n* The inhibitAnyPolicy counter does not count self-issued certificates\n* The requireExplicitPolicy counter does not count self-issued certificates",
2560
+
"createdAt": "2025-10-06T20:35:16Z",
2561
+
"updatedAt": "2025-10-06T20:37:18Z"
2562
+
}
2563
+
]
2556
2564
},
2557
2565
{
2558
2566
"number": 147,
@@ -8721,6 +8729,222 @@
8721
8729
"comments": []
8722
8730
}
8723
8731
]
8732
+
},
8733
+
{
8734
+
"number": 149,
8735
+
"id": "PR_kwDOJIBkVc6sSGpH",
8736
+
"title": "Unify the two branches in the consistency proof check",
"body": "Also replace prepending to the proof list with removing in the other branch. It makes it a little obvious how to implement this without making a copy of the proof. This should also hopefully make the relationship between inclusion and consistency proof evaluation clearer.\r\n\r\nWhile I'm here, use '1.' for the steps so we don't have to renumber it as it changes.\r\n\r\n(CC @nharper)",
"body": "As I'm re-implementing this logic, I found a panic in the original version of my code when `n = 0` due to an underflow. The fact that `[start, end)` is a subtree of the tree of size `n` implies that `0 <= start < end <= n` so it must be the case that `end > 0` and `n > 0`, but maybe we should add an explicit note about that?",
8775
+
"createdAt": "2025-10-06T18:05:34Z",
8776
+
"updatedAt": "2025-10-06T20:51:48Z"
8777
+
},
8778
+
{
8779
+
"originalPosition": 16,
8780
+
"body": "We could collapse lines 520-523:\r\n```suggestion\r\n1. Right-shift `fn`, `sn`, and `tn` equally until either `fn` is `sn` or both `sn` is not `tn` and `LSB(sn)` is not set.\r\n```",
8781
+
"createdAt": "2025-10-06T20:22:20Z",
8782
+
"updatedAt": "2025-10-06T20:51:48Z"
8783
+
},
8784
+
{
8785
+
"originalPosition": 16,
8786
+
"body": "And maybe swap the until to the start for consistency with below (or switch below to be consistent with this). Although maybe this doesn't read as well:\r\n```suggestion\r\n1. Until either `fn` is `sn` or both `sn` is not `tn` and `LSB(sn)` is not set, right-shift `fn`, `sn`, and `tn` equally.\r\n```",
8787
+
"createdAt": "2025-10-06T20:50:24Z",
8788
+
"updatedAt": "2025-10-06T20:51:48Z"
8789
+
}
8790
+
]
8791
+
},
8792
+
{
8793
+
"id": "PRR_kwDOJIBkVc7FJEfT",
8794
+
"commit": {
8795
+
"abbreviatedOid": "27988ca"
8796
+
},
8797
+
"author": "davidben",
8798
+
"authorAssociation": "OWNER",
8799
+
"state": "COMMENTED",
8800
+
"body": "",
8801
+
"createdAt": "2025-10-06T21:27:31Z",
8802
+
"updatedAt": "2025-10-06T21:39:59Z",
8803
+
"comments": [
8804
+
{
8805
+
"originalPosition": 15,
8806
+
"body": "Hmm... how about we just make the function check the preconditions? It's fallible anyway, and makes it consistent with the inclusion proof version. Arguably it's redundant with the \"type signature\" but people will be sloppy.",
8807
+
"createdAt": "2025-10-06T21:27:31Z",
8808
+
"updatedAt": "2025-10-06T21:39:59Z"
8809
+
},
8810
+
{
8811
+
"originalPosition": 16,
8812
+
"body": "Ah yeah, probably good to make that consistent. No strong feelings about whether the condition or the action is first. I did condition, action just to match what was previously there.\r\n\r\nRe collapsing, I had one version where it was one expression, but having both AND and OR in the same English expression felt pushing it w.r.t. readability. Though it's not toooo bad if you put the condition last? I dunno. No very strong feelings either way. WDYT?\r\n\r\nStrictly speaking, to convince yourself that the two are the same, you have to believe that `sn` can't become `tn` partway through the loop and through you off. But if `sn != tn`, we know that `sn < tn`, which means that we'll hit \"`LSB(sn)` is not set\" before `sn` becomes equal to `tn`.",
8813
+
"createdAt": "2025-10-06T21:38:30Z",
8814
+
"updatedAt": "2025-10-06T21:39:59Z"
8815
+
}
8816
+
]
8817
+
},
8818
+
{
8819
+
"id": "PRR_kwDOJIBkVc7FJfwr",
8820
+
"commit": {
8821
+
"abbreviatedOid": "d2d5021"
8822
+
},
8823
+
"author": "lukevalenta",
8824
+
"authorAssociation": "COLLABORATOR",
8825
+
"state": "COMMENTED",
8826
+
"body": "",
8827
+
"createdAt": "2025-10-06T21:52:33Z",
8828
+
"updatedAt": "2025-10-06T21:52:33Z",
8829
+
"comments": [
8830
+
{
8831
+
"originalPosition": 16,
8832
+
"body": "I think the \u2018both\u2019 helps to make it unambiguous (and Gemini agreed), but it does take a little more brain power to process so I\u2019m fine with keeping it separated out.\r\n\r\nOoh yeah that\u2019s a good point about checking if sn is tn initially vs in the loop condition. I think not condensing is the right call.",
8833
+
"createdAt": "2025-10-06T21:52:33Z",
8834
+
"updatedAt": "2025-10-06T21:54:31Z"
8835
+
}
8836
+
]
8837
+
},
8838
+
{
8839
+
"id": "PRR_kwDOJIBkVc7FJ34t",
8840
+
"commit": {
8841
+
"abbreviatedOid": "d2d5021"
8842
+
},
8843
+
"author": "davidben",
8844
+
"authorAssociation": "OWNER",
8845
+
"state": "COMMENTED",
8846
+
"body": "",
8847
+
"createdAt": "2025-10-06T22:25:10Z",
8848
+
"updatedAt": "2025-10-06T22:25:11Z",
8849
+
"comments": [
8850
+
{
8851
+
"originalPosition": 16,
8852
+
"body": "Sounds good. Leaving as-is then!",
8853
+
"createdAt": "2025-10-06T22:25:10Z",
8854
+
"updatedAt": "2025-10-06T22:25:11Z"
8855
+
}
8856
+
]
8857
+
}
8858
+
]
8859
+
},
8860
+
{
8861
+
"number": 150,
8862
+
"id": "PR_kwDOJIBkVc6sUSSZ",
8863
+
"title": "Add an appendix that explains the proof procedures",
0 commit comments