Closed bdehamer closed 8 months ago
Just to check, there isn’t a bug in the Sigstore implementation of the TSA, correct? Have we confirmed that the DER encoding matches the RFC?
Just to check, there isn’t a bug in the Sigstore implementation of the TSA, correct? Have we confirmed that the DER encoding matches the RFC?
@haydentherapper, no, the Sigstore TSA implementation is fine. I've done a fairly meticulous comparison of the TSA-generated timestamps to the spec at this point and things look good (though there was one very minor issue I did uncover).
I'm pretty sure that the encoding issue I'm addressing here isn't even significant as I was able to verify the previous timestamps successfully with both openssl
and the timestamp-cli
. It was just bugging me that it didn't match exactly the TSA-issued timestamps.
@bdehamer Thanks, I'll go update the TSA service now (dependabot didn't pick up the change since we're using commits)
Updates the
d.txt.good.sigstore
andd.txt.tsa-timestamp-error.sigstore
bundles with new RFC3161 timestamp values.The original timestamps each included an encoding quirk (constructed OCTET STRINGs vs. pure, DER-encoded OCTET STRINGs) that didn't quite match the structure of the timestamps generated by the
timestamp-authority
service. The updated timestamp values included here fix the encoding issue and look more the timestamps you'd receive from TSA (take a look at https://github.com/sigstore/sigstore-js/pull/912 if you wanna see the specifics of the encoding change).The timestamp in
d.txt.good.sigstore
has a signing time that falls within the validity period of the bundle's Fulcio-issued signing certificate:The timestamp in
d.txt.tsa-timestamp-error.sigstore
has a signing time that falls OUTSIDE the validity period of the bundle's Fulcio-issued signing certificate:Other than changes to the
signedTimestamp
values, the bundles are unchanged.I tested these changes against both
sigstore-js
andsigstore-go
and got the expected results.