add new trusted_root.json target #584

bdehamer · 2023-01-07T01:08:47Z

Signed-off-by: Brian DeHamer bdehamer@github.com

Summary

I'm not sure we're ready to implement this yet, but I thought I'd take a crack and gathering all of the keys/certs we're currently distributing via TUF and massaging them into the TrustedRoot format (JSON-serialized) defined in sigstore/protobuf-specs.

From a client perspective, it sure seems like this would make things much easier -- having a single structured target to download vs. juggling multiple targets (and also parsing metadata from the targets.json file).

Signed-off-by: Brian DeHamer <bdehamer@github.com>

bdehamer · 2023-01-07T01:13:16Z

targets/trusted_root.json

+      },
+      "validFor": {
+        "start": "2021-03-07T03:20:29.000Z",
+        "end": "2031-02-23T03:20:29.000Z"


This end date should probably be whatever date we stopped signing w/ this certificate but I wasn't sure when that was.

June 30 2022 would be reasonable IIRC, but if you want to be even more safe, just do end of 2022.

@asraa if you remember a more precise date

kommendorkapten · 2023-01-09T14:00:22Z

Nice, thanks for doing this!

kommendorkapten · 2023-01-09T14:01:33Z

targets/trusted_root.json

+      "hashAlgorithm": "SHA2_256",
+      "publicKey": {
+        "rawBytes": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEbfwR+RJudXscgRBRpKX1XFDy3PyudDxz/SfnRi1fT8ekpfBd2O1uoz7jr3Z8nKzxA69EUQ+eFCFI3zeubPWU7w==",
+        "keyDetails": "PKIX_ECDSA_P256_SHA_256"


We should include the validFor attribute too for both this and the 2022 instance, so a client could pick up the correct instance based on the validity time. For 2022 we should not have an end date.

asraa

Thank you!!! I actually think we should start a new milestone for a v6 root signing. I will create one, and add in the relevant checklist items (convening on a date on the calendar, testing, etc)

Naming comment: I would prefer this would be named something that indicates the protobuf type and version of this object OR to have the type and version encoded in the object itself.
If naming suffices, maybe something like dev.sigstore.trustroot.v1.TrustedRoot.json. Someone else can do better that me...

cc @jku

targets/trusted_root.json

kommendorkapten · 2023-01-09T15:58:04Z

targets/trusted_root.json

+      "hashAlgorithm": "SHA2_256",
+      "publicKey": {
+        "rawBytes": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2G2Y+2tabdTV5BcGiBIx0a9fAFwrkBbmLSGtks4L3qX6yYY0zufBnhC8Ur/iy55GhWP/9A/bY2LhC30M9+RYtw==",
+        "keyDetails": "PKIX_ECDSA_P256_SHA_256"


Same here, we should include validFor, without the end timestamp.

bdehamer · 2023-01-09T16:55:42Z

Here's the list of values we need to fill-in still (values I wasn't able to deduce from the existing TUF data):

validFor period for the tlog public key (just the start timestamp)
validFor period for the "test" ctlog public key (both start and end timestamps)
validFor period for the "2022" ctlog public key (just the start timestamp)
Correct end timestamp for the older of the two CAs

targets/trusted_root.json

haydentherapper · 2023-01-09T17:14:48Z

targets/trusted_root.json

+      },
+      "validFor": {
+        "start": "2021-03-07T03:20:29.000Z",
+        "end": "2031-02-23T03:20:29.000Z"


June 30 2022 would be reasonable IIRC, but if you want to be even more safe, just do end of 2022.

@asraa if you remember a more precise date

targets/trusted_root.json

Co-authored-by: Hayden B <hblauzvern@gmail.com> Signed-off-by: Brian DeHamer <bdehamer@github.com>

Signed-off-by: Brian DeHamer <bdehamer@github.com>

asraa · 2023-01-19T14:55:57Z

Thanks for the updates! The remaining work from your comment is still outstanding -- by EOW I'll try to help as well.

But this is still on my roadmap to merge soon for https://github.com/sigstore/root-signing/milestone/3

targets/trusted_root.json

bdehamer · 2023-01-21T02:06:50Z

targets/trusted_root.json

+        "rawBytes": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEiPSlFi0CmFTfEjCUqF9HuCEcYXNKAaYalIJmBZ8yyezPjTqhxrKBpMnaocVtLJBI1eM3uXnQzQGAJdJ4gs9Fyw==",
+        "keyDetails": "PKIX_ECDSA_P256_SHA_256",
+        "validFor": {
+          "start": "2022-01-01T00:00:00.000Z"


Need a more accurate start date here

I believe around Sigstore GA, Oct 20th's a good bound.

Updated to match Sigstore's GA date.

Ah, I think it is still 2022-01-01 - maybe a missing commit?

bdehamer · 2023-01-21T02:07:32Z

targets/trusted_root.json

+          "start": "2021-03-07T03:20:29.000Z",
+          "end": "2022-01-01T00:00:00.000Z"


Need accurate start/end dates here

So this key was used until Sigstore went GA around october 20th 2022

however, that was using the https://ctfe.sigstore.dev as the base URL. It's almost like there should be an entry for that URL until oct 20th, and then onwards for /test

@haydentherapper not really sure....

ping @haydentherapper is this actually being used anymore? or what do you think about the proposal to have the entry for https://ctfe.sigstore.dev as the old signing key from it's start date to GA, and then this current entry for /test from GA to current.

Signed-off-by: Brian DeHamer <bdehamer@github.com>

kommendorkapten · 2023-01-23T09:48:42Z

@woodruffw FYI

Not sure how python are dealing with the Sigstore trust root, but from v6 and forward (scheduled for February 28th) the entire trust root will be shipped as a single target to avoid all the stitching in the client.

woodruffw · 2023-01-23T15:12:33Z

Thanks for the ping! Yeah, we'll probably need to update our TUF use to handle this. Is there going to be a compatibility period where both formats are distributed in the TUF repo?

kommendorkapten · 2023-01-23T15:24:17Z

Yeah, as there are some old clients out in the wild, I think the targets will be published using both formats for a fairly long time, but can't provide any more accurate info than that. So far, it's only sigstore-js that I know have the new updated format on the roadmap.

asraa · 2023-01-25T14:50:21Z

! Yeah, we'll probably need to update our TUF use to handle this. Is there going to be a compatibility period where both formats are distributed in the TUF repo?

Yes, I won't be removing the existing current targets, just supporting this new format to allow clients to move when necessary.

asraa · 2023-01-25T14:54:42Z

targets/trusted_root.json

+      },
+      "validFor": {
+        "start": "2022-04-13T20:06:15.000Z",
+        "end": "2031-10-05T13:56:58.000Z"


should we omit the end here? it's the cert end date as I see, but not the end of service date. but either way it's an upper bound on it so can always be updated.

I'm still leaning towards omission of the end, but doesn't matter to me since we can always update it when it's EOL is known.

On the consuming side, I personally find end here confusing: it's not the "end" in terms of service date (as you said), but only the point after which newly issued certs shouldn't be chained up to this particular root or intermediate.

Given that that information should already be embedded into the certs themselves, I'm in favor of omitting it.

(My understanding is that start needs to be kept around for filtering purposes, i.e. we don't want to include a cert in the X.509 verification context before it's actually become active. But that too should be handled during the client verification process, so I'm not 100% sure what purpose it has in the bundle here.)

+1, I'd like to leave this comment open for addressing on Brian's side

@bdehamer to add to the TODO for fixup

Wait, the end date is not meant to indicate the certificate's validity period. That is redundant as @woodruffw said. It's supposed to indicate when that certificate/chain was decommissioned. We typically can't just rely on a list of certs with a start value (and so assume that the next start indicates the "current" end), there is going to be some short overlap during time a new certificate is deployed.

Agree - I added this to the follow-up issue Brian posted to resolve

asraa · 2023-01-25T14:58:01Z

targets/trusted_root.json

+          "start": "2021-03-07T03:20:29.000Z",
+          "end": "2022-01-01T00:00:00.000Z"


So this key was used until Sigstore went GA around october 20th 2022

however, that was using the https://ctfe.sigstore.dev as the base URL. It's almost like there should be an entry for that URL until oct 20th, and then onwards for /test

@haydentherapper not really sure....

asraa · 2023-01-25T14:58:14Z

targets/trusted_root.json

+        "rawBytes": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEiPSlFi0CmFTfEjCUqF9HuCEcYXNKAaYalIJmBZ8yyezPjTqhxrKBpMnaocVtLJBI1eM3uXnQzQGAJdJ4gs9Fyw==",
+        "keyDetails": "PKIX_ECDSA_P256_SHA_256",
+        "validFor": {
+          "start": "2022-01-01T00:00:00.000Z"


I believe around Sigstore GA, Oct 20th's a good bound.

The new start date matches the date of the first record added to the log Signed-off-by: Brian DeHamer <bdehamer@github.com>

The start date for the https://ctfe.sigstore.dev/2022 key has been updated to match Sigstore's October 20th, 2022 GA date. Signed-off-by: Brian DeHamer <bdehamer@github.com>

trishankatdatadog · 2023-02-07T16:22:01Z

Interesting! So do I understand correctly when I say that the TrustedRoot will be distributed as a TUF target, not metadata?

kommendorkapten · 2023-02-08T08:16:42Z

@trishankatdatadog Exactly! Today the components that makes up the TrustedRoot are shipped as individual targets, with metadata attached to them that describes them. With this PR, we can assemble the trusted root once, with all the semantics implicit via a well-defined structure, so we save the clients a lot of work as they don't need to parse the metadata and collect all the targets to assemble the trusted root.

asraa · 2023-02-08T14:45:37Z

@bdehamer do you want to merge and file a follow-up issue with a v6 milestone on the remaining TODOs?

woodruffw · 2023-02-08T15:05:38Z

I'm very excited for these changes! Anything that reduces the number of TUF repo round-trips that Sigstore clients have to make is a win, in my book 🙂

One question from the consuming side: is the trusted_root.json target meant to contain the total "history" of all Sigstore trust root material, or just the "latest" root material? From the initially checked-in JSON it seems like the former (which is what we want on the client side, so that we don't e.g. have to fetch multiple CTFE keys separately), but I wanted to make sure my understanding of that was correct.

asraa · 2023-02-08T15:08:25Z

One question from the consuming side: is the trusted_root.json target meant to contain the total "history" of all Sigstore trust root material, or just the "latest" root material?

I think you are correct. It's the total history of the TRUSTED material. If any previous keys get compromised, they will disappear, but it's all the latest view on the history of all trusted material (there, I used both quoted words in it!)

bdehamer · 2023-02-08T17:59:17Z

@asraa yeah, I think we can merge this and I'll add the remaining TODOs in an issue.

haydentherapper · 2024-02-29T20:13:30Z

@kommendorkapten @bdehamer How did you generate this? Did you craft this by hand?

cc @lkatalin @sabre1041

kommendorkapten · 2024-02-29T20:40:56Z

@haydentherapper I wrote this wacky tool a while back, it's very hacky https://github.com/kommendorkapten/trtool/blob/main/cmd/trtool/app/initroot.go

I have some more features that's not pushed yet, like add more content to an existing trust root. I'll try to fix that very soon and push the changes.

haydentherapper · 2024-02-29T20:45:35Z

Thanks! @lkatalin this might be a good starting point

lkatalin · 2024-02-29T20:48:38Z

Thanks, that's very helpful!

add new trusted_root.json target

3680075

Signed-off-by: Brian DeHamer <bdehamer@github.com>

bdehamer mentioned this pull request Jan 7, 2023

Use root-of-trust bundle as the TUF target file #539

Closed

bdehamer commented Jan 7, 2023

View reviewed changes

kommendorkapten reviewed Jan 9, 2023

View reviewed changes

asraa reviewed Jan 9, 2023

View reviewed changes

targets/trusted_root.json Show resolved Hide resolved

kommendorkapten reviewed Jan 9, 2023

View reviewed changes

haydentherapper reviewed Jan 9, 2023

View reviewed changes

kommendorkapten mentioned this pull request Jan 10, 2023

Added a mime type to the trusted root, as that's expected to be seria… sigstore/protobuf-specs#54

Merged

bdehamer and others added 3 commits January 10, 2023 09:46

Update targets/trusted_root.json

e60deec

Co-authored-by: Hayden B <hblauzvern@gmail.com> Signed-off-by: Brian DeHamer <bdehamer@github.com>

add mediaType to trusted root

e16a8a1

Signed-off-by: Brian DeHamer <bdehamer@github.com>

update end date for original Fulcio CA

90cb9c6

Signed-off-by: Brian DeHamer <bdehamer@github.com>

bdehamer commented Jan 21, 2023

View reviewed changes

targets/trusted_root.json Outdated Show resolved Hide resolved

bdehamer commented Jan 21, 2023

View reviewed changes

take a wag at dates for ctlog/tlog keys

cdc6d42

Signed-off-by: Brian DeHamer <bdehamer@github.com>

asraa reviewed Jan 25, 2023

View reviewed changes

bdehamer added 2 commits January 25, 2023 16:11

update start date for rekor key

9f2fbc7

The new start date matches the date of the first record added to the log Signed-off-by: Brian DeHamer <bdehamer@github.com>

update start date for ctfe/2022 key

31e8b64

The start date for the https://ctfe.sigstore.dev/2022 key has been updated to match Sigstore's October 20th, 2022 GA date. Signed-off-by: Brian DeHamer <bdehamer@github.com>

bdehamer mentioned this pull request Jan 27, 2023

TUF integration sigstore/sigstore-js#274

Merged

woodruffw mentioned this pull request Jan 31, 2023

TUF: Support "bundled" trust root sigstore/sigstore-python#488

Closed

asraa enabled auto-merge (squash) February 8, 2023 18:08

bdehamer mentioned this pull request Feb 8, 2023

Finalize TrustedRoot target #616

Closed

asraa approved these changes Feb 8, 2023

View reviewed changes

asraa merged commit 49d1933 into sigstore:main Feb 8, 2023

bdehamer deleted the bdehamer/trusted-root branch February 8, 2023 23:07

		"start": "2021-03-07T03:20:29.000Z",
		"end": "2022-01-01T00:00:00.000Z"

add new trusted_root.json target #584

add new trusted_root.json target #584

Conversation

bdehamer commented Jan 7, 2023

Summary

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kommendorkapten commented Jan 9, 2023

Choose a reason for hiding this comment

asraa left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bdehamer commented Jan 9, 2023 • edited Loading

Choose a reason for hiding this comment

asraa commented Jan 19, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kommendorkapten commented Jan 23, 2023

woodruffw commented Jan 23, 2023

kommendorkapten commented Jan 23, 2023

asraa commented Jan 25, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trishankatdatadog commented Feb 7, 2023

kommendorkapten commented Feb 8, 2023

asraa commented Feb 8, 2023

woodruffw commented Feb 8, 2023

asraa commented Feb 8, 2023

bdehamer commented Feb 8, 2023

haydentherapper commented Feb 29, 2024

kommendorkapten commented Feb 29, 2024

haydentherapper commented Feb 29, 2024

lkatalin commented Feb 29, 2024

asraa left a comment •

edited

Loading

bdehamer commented Jan 9, 2023 •

edited

Loading