| dts |
So, I've mentioned various solutions over the years. AWS offers a "cloud" HSM that isn't very cloud, but it supports Ed25519. There's also more recent work by CNCF or the Linux Foundation (I forget which) to provide a hosted root of trust for systems like TUF.I would strongly advocate the DA picking up the latter. I'll find a link. |
| dts |
https://www.sigstore.dev/ |
| dts |
https://dlorenc.medium.com/using-the-update-framework-in-sigstore-dc393c... |
| dts |
Alternatively, I could help the DA leverage the YubiHSMs to provide an offline root of trust compatible with TUF. That wouldn't be that hard to deploy.Still, I would advocate for using Sigstore. The YubiHSMs are a sunk cost, but that's hardly a reason to use them over better options that have emerged since. |
| dts |
It will also be easier to port the process to Packagist if they don't need to fully operate their own root of trust. |
| dts |
Also, while it would be straightforward to operate a TUF root of trust on YubiHSM, it would be built by us. Support for Sigstore is probably going to be available "off the shelf." |
| drumm |
sigstore, that’s it. |
| drumm |
I’m not really prepared to put much real thought into this today, got paged awake at 4am. @hestenet (he/him) ^ to put that on your radar to maybe reach out to them for some partnership deal, if we think it’ll fulfill our needs. And @Christopher Gervais this is what I was trying to remember for a couple meetings. |
| hestenet (he/him) |
I'll start doing some looking around. |
| Christopher Gervais |
This is interesting, but I'm having a hard time visualizing how this would work. |
| dts |
@Christopher Gervais The second link I posted provides some overview of TUF + Sigstore |
| Christopher Gervais |
Would we ask Sigstore to sign our root keys, and then distribute the Sigstore root.json with the Composer plugin? |
| Christopher Gervais |
that seems to be what the Medium article is saying |
| dts |
I would need to read in detail to understand how it comes together. I just know it's intended to be officially supported and that I trust the people behind Sigstore. |
| dts |
Also, that running our own root is ultimately going to be harder and less secure than picking up something like Sigstore. |
| Christopher Gervais |
if so, wouldn't that mean that any other project that also has keys signed by this Super Root could become the root of trust for our targets? |
| Christopher Gervais |
or rather, that targets.json signed by them would also verify as valid? (edited) |
| dts |
I don't believe so, if you mean that we would need to trust other projects using Sigstore. |
| dts |
I would be shocked if they designed it in a way that each project becomes a new attack surface for all projects using Sigstore. |
| dts |
I can properly wrap my head around TUF + Sigstore if that would help people here. I just haven't put in the time yet. |
| Christopher Gervais |
I guess this idea of delegating root is foreign to me. |
| Christopher Gervais |
The TUF spec, afaict, only defines delegation of targets |
| Christopher Gervais |
these seem to be scoped by path, to avoid this kind of this |
| Christopher Gervais |
@dts I would appreciate if you could read into it more. I've spent about an hour on it so far, and I just have more questions than when I started :slightly_smiling_face: |
| dts |
It's also possible for us to pick up Sigstore tools and run our own root: https://blog.sigstore.dev/sigstore-bring-your-own-stuf-with-tuf-40febfd2... |
| dts |
The first blog post I linked suggests that Sigstore can delegate a root to us. |
| dts |
0 VCrVxOSI0aryZy58.png |
| dts |
So, we could presumably do everything as we're doing it now, but updating our root would be via Sigstore rather than our own tools. We would ship Sigstore's public keys in Drupal itself. But like you mentioned earlier, I'm not sure how that prevents other projects from harming us unless the root delegation itself is restricted by Sigstore. |
| dts |
The blog post suggests that this approach extends TUF by introducing a new type of delegation for roots: For other projects that want to piggy-back on a trusted root but still use their own keys and signing infrastructure, we can create a custom role that authorizes their keys to sign their own artifacts through a “delegation”. |
| Christopher Gervais |
right. that's the part we'd need to know more about. |
| Christopher Gervais |
I just reviewed the TUF spec for any mention of something like that |
| Christopher Gervais |
the only place they mention "partial trust" (which I described as "scope" earlier) is with path prefixes in targets |
| dts |
In TUF proper, yes. I get the impression that Sigstore expects an extension to TUF for scoped root delegation. |
| Christopher Gervais |
FWIW, PyPi is looking to adopt some of their tools: https://github.com/theupdateframework/taps/pull/141/files.AFAICT, this is to simplify delegation of targets to developers |
| dts |
That may be an easier case, as TUF can (out of the box) delegate target signing in various ways. |
| Christopher Gervais |
part of the extensions they're talking about discuss using CA-signed certs, in place of keys, for signing metadata |
| Christopher Gervais |
I think I read part where they were saying these could be short-lived, the the CA could verify that the cert was valid when the metadata was signed |
| Christopher Gervais |
or something like that |
| dts |
We should probably talk with TUF/Sigstore people. I think this territory may be underspecified, even if there's consensus that such an integration ought to be official. |
| Christopher Gervais |
but I think that revives problems with revocation, in case of compromise, etc. |
| Christopher Gervais |
agreed |
| dts |
My preference would be to meet in person for up to a week to hammer something out with people involved in TUF. |
| dts |
Like, I can take the week away from Pantheon and do a deep dive. |
| Christopher Gervais |
for the time-being, I think the plan is to stick with keys on disk, in an short-lived environment, to prove out the rest of the system |
| dts |
That's 100% just fine. None of this should change the fundamental design of the system. |
| Christopher Gervais |
Unfortunately, I can't really take a week away from Consensus any time soon. |
| Christopher Gervais |
I think I'd also need to ask for some kind of sponsorship |
| drumm |
I definitely would appreciate guidance on all the things we can tune, like rotation intervals and root key handling. |
| dts |
I'm not asking for you to take the time, just me to find some clarity in this space through my own efforts. |
| dts |
My goal would be to return from the collab with example code that melds Sigstore + TUF in the way we'd need to avoid managing a root ourselves. |
| Christopher Gervais |
oh, i see. You mean the TUF core folks, etc. |
| dts |
Yes, likely in NYC. |
| Christopher Gervais |
yeah, that'd be great |
| dts |
I'm already coordinating (over the last tens of minutes) with TUF upstream. They want to make this happen. I'll meet with them tomorrow. This is what they have so far: https://docs.google.com/document/d/1WPOXLMV1ASQryTRZJbdg3wWRR4ckK558kUnx... |
| dts |
I can chime in from the Sigstore side and say: this is absolutely something that the Sigstore community is willing to support. There’s a lot of tricky design work here that we should get right before we roll it out, but if we feel comfortable with it (with a lot of feedback from the TUF community) we’d be willing to sign Drupal certs. |
TravisCarden, tedbow, hestenet, dts, drumm, fjgarlin, Christopher Gervais, phenaproxima
Comments
Comment #2
hestenetComment #10
hestenet