Discussion of Fulcio TAP (TAP 18)

[mnm678]

There are some remaining issues on the Fulcio TAP:

• link to Sigstore documentation (as it is created) for root signing, signing, bundles, and verification

[lukpueh]

FYI: A fully working sigstore signer is available in the securesystemslib v0.27.0. It can already be used in the python-tuf reference implementation via the new signer API.

The API is still experimental and development continues in: securesystemslib/signer/_sigstore_signer.py.

---

NOTEs to TAP editors:

The following two decisions are currently hard-coded:

• use offline verification
• use sigstore production instance for signing and verifying

I think we should configure the latter via the public key? It should always remain the same for a given public key.

Also, "offline" verification is not really offline. IIUC it skips talking to rekor, but still does a TUF client update with Fulcio.

Last but not least, I opted for storing the sigstore bundle in a separate field, and additionally copying the signature from the bundle into the "sig" field, to remain compatible with the current TUF specification (following discussion in: #168 (comment)). The signature on the wire now looks something like:

{
  "keyid": KEYID,
  "sig": SIGNATURE, #  bundle.message_signature.signature.hex()
  "bundle": BUNDLE # bundle.to_dict()
}

[joshuagl]

Nice to see an implementation of this TAP, thanks @lukpueh!

I agree with the assertion that the Sigstore instance should not be hard-coded. Private deployments seem likely and we want TUF to remain flexible.

What would you recommend wrt the "offline" is not really offline observation? Should this be a note in the TAP (do we need a TAP to describe truly offline/airgapped TUF repositories?)

I opened #175 to update the TAP to the key format you've used in the securesystemslib implementation.

[jku]

For reference secure-systems-lab/dsse#61 is adityas signature extension proposal for DSSE

[adityasaky]

After that's merged, the TAP should be updated in the signature format section: https://github.com/theupdateframework/taps/blob/master/tap18.md#signature-format.

Specifically, BUNDLE should be replaced in favour of the DSSE signature extension and possible similar custom fields should be defined for the legacy signature wrapper? The issue with using the sigstore bundle is it's designed to wrap around a signature envelope with extra verification materials, and is not meant to be embedded for a signature in an existing envelope.

[jku]

TAP18 and the experimental implementation in securesystemslib should definitely be updated if there's a direct way to be consistent with planned DSSE formats.

The issue with using the sigstore bundle is it's designed to wrap around a signature envelope with extra verification materials, and is not meant to be embedded for a signature in an existing envelope.

If you are talking about e.g. using the VerificationMaterial proto instead of Bundle within the signature, then that sounds fine to me (although I notice VerificationMaterial does not have a media_type field or other versioning in it -- I'm not super familiar with protobufs so maybe that's not an issue)

[adityasaky]

sigstore/protobuf-specs#145

We actually discussed using a subset of VerificationMaterials to omit the key ID as the signature has its own key ID field (sigstore/sig-clients#9). Once that PR is merged, for DSSE, the TAP may be updated to use the extension I think?

versioning

The proposed message also omits this, but that's because the kind field which holds the media type + version must be defined by securesystemslib as that is a common wrapper for other potential DSSE extensions.