Consider replacing the bundle with DSSE + `ext`/`VerificationMaterial`

[kommendorkapten]

DSSE has been updated to support signature extensions, which was not the case when we started the work on the bundle. This now allows us to put the verification material as an extension to the signature, instead of layering the envelope in a bundle. This with the combination of dropping DSSE support from Rekor, can improve our situation, and open up for an easier PQC adoption. Consider this:

$ wc -c tmp-att.json
    9943 tmp-att.json
$ jq . tmp-att.json
{
  "mediaType": "application/vnd.dev.sigstore.bundle.v0.3+json",
  "verificationMaterial": {
    "certificate": {
      "rawBytes": "MIIG..."
    },
    "tlogEntries": [
      {
        "logIndex": "97913944",
        "logId": {
          "keyId": "wNI9atQGlz+VWfO6LRygH4QUfY/8W4RFwiT5i5WRgB0="
        },
        "kindVersion": {
          "kind": "dsse",
          "version": "0.0.1"
        },
        "integratedTime": "1716998987",
        "inclusionPromise": {
          "signedEntryTimestamp": "MEUC..."
        },
        "inclusionProof": {
          "logIndex": "93750513",
          "rootHash": "gMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=",
          "treeSize": "93750515",
          "hashes": [
            "uCO3hICjSShYg1eSenlwTjKq+JLB3ZCyAlvjnh/3yKE=",
            "8KDdwXCQI9jhS7ufVuC2BRnD9yXb5Sfb+aLH8+BuSiQ=",
            "JruHw9VeLnhrdEVV5mkJr8r+nZ1xqiAydH5iDPVP5fs=",
            "GqhYL9+znswADy/JjZXofHxLmeE37Jx2HLJRGYjKeAA=",
            "L7xfPpL8AE9ijsQTZeSX7QcbyCPHSxS7ch8Rc4JJVhQ=",
            "DZjlMkk1MuzKvAUiWk9KMj9eQjzPpj5GHG9I2Vp+yaU=",
            "Tgve40VPFfuei+0nhupdGpfPPR+hPpZjxgTiDT8WNoY=",
            "wV+S/7tLtYGzkLaSb6UDqexNyhMvumHK/RpTNvEZuLU=",
            "uwaWufty6sn6XqO1Tb9M3Vz6sBKPu0HT36mStxJNd7s=",
            "jUfeMOXQP0XF1JAnCEETVbfRKMUwCzrVUzYi8vnDMVs=",
            "xQKjzJAwwdlQG/YUYBKPXxbCmhMYKo1wnv+6vDuKWhQ=",
            "cX3Agx+hP66t1ZLbX/yHbfjU46/3m/VAmWyG/fhxAVc=",
            "sjohk/3DQIfXTgf/5XpwtdF7yNbrf8YykOMHr1CyBYQ=",
            "98enzMaC+x5oCMvIZQA5z8vu2apDMCFvE/935NfuPw8="
          ],
          "checkpoint": {
            "envelope": "rekor.sigstore.dev - 2605736670972794746\n93750515\ngMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=\n\n— rekor.sigstore.dev wNI9ajBFAiEAu9Z/WsClrI/ejoMeXW9QRkDIMr3mXkzSBHDUjw+onw8CIBp9UrmrSf+rl0cM0Xj3zgqChtfMskkeEhgQ7T7nocF1\n"
          }
        },
        "canonicalizedBody": "eyJh..."
      }
    ],
    "timestampVerificationData": {}
  },
  "dsseEnvelope": {
    "payload": "eyJf...",
    "payloadType": "application/vnd.in-toto+json",
    "signatures": [
      {
        "sig": "MEQCIHiO3LhNrbV0Lz7sazQ8a3okIP3DBi45t5oQAQMUV1l/AiBO+NyF4JglqYKPPk2h2tnUFGi37g0wnGUWU/8ihQlOWQ=="
      }
    ]
  }
}

Note that for simplicity I have stripped the payload and the canonicalizedBody.
The payload is a simple SLSA build provenance attestation. The canonicalized body is a rekor response:

{
  "apiVersion": "0.0.1",
  "kind": "dsse",
  "spec": {
    "envelopeHash": {
      "algorithm": "sha256",
      "value": "7e81790fdeb9b259b4d8f39ad2f32fef010afc8813400b7351516d03b0d2a415"
    },
    "payloadHash": {
      "algorithm": "sha256",
      "value": "f553ffed4c53bcb343358e3835ee3f5185d70f1ba2a96666980aa63e95370ca4"
    },
    "signatures": [
      {
        "signature": "MEQCIHiO3LhNrbV0Lz7sazQ8a3okIP3DBi45t5oQAQMUV1l/AiBO+NyF4JglqYKPPk2h2tnUFGi37g0wnGUWU/8ihQlOWQ==",
        "verifier": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdqakNDQmhTZ0F3SUJBZ0lVQlBBVmtsRlJ5MUkxOUR4ckwycHBleUFZNXJ3d0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpRd05USTVNVFl3T1RRM1doY05NalF3TlRJNU1UWXhPVFEzV2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVZdVJFWjFYMElQOXQ3amlFQ3RPNXhKeFNSdHkrd1BiQkl3TzgKbkhJZHhmWitXZWRnTHh3WnZGdzJYOHA2cE8wQ2VRQ1l2T25PaTZBRnFzbm9aY29GL3FPQ0JUTXdnZ1V2TUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVWNVF5CnhjaXZDNmJSNWNydEEwVHFLUFo4bnNrd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d1dnWURWUjBSQVFIL0JGQXdUb1pNYUhSMGNITTZMeTluYVhSb2RXSXVZMjl0TDJOc2FTOWpiR2t2TG1kcApkR2gxWWk5M2IzSnJabXh2ZDNNdlpHVndiRzk1YldWdWRDNTViV3hBY21WbWN5OW9aV0ZrY3k5MGNuVnVhekE1CkJnb3JCZ0VFQVlPL01BRUJCQ3RvZEhSd2N6b3ZMM1J2YTJWdUxtRmpkR2x2Ym5NdVoybDBhSFZpZFhObGNtTnYKYm5SbGJuUXVZMjl0TUI4R0Npc0dBUVFCZzc4d0FRSUVFWGR2Y210bWJHOTNYMlJwYzNCaGRHTm9NRFlHQ2lzRwpBUVFCZzc4d0FRTUVLR1poWldZeVpHUmtPREZpTURjek5qYzBPRFF4TTJFM1l6WTBObU5rTUdKbVl6STJZekF3CllUQXdHQVlLS3dZQkJBR0R2ekFCQkFRS1JHVndiRzk1YldWdWREQVZCZ29yQmdFRUFZTy9NQUVGQkFkamJHa3YKWTJ4cE1CNEdDaXNHQVFRQmc3OHdBUVlFRUhKbFpuTXZhR1ZoWkhNdmRISjFibXN3T3dZS0t3WUJCQUdEdnpBQgpDQVF0REN0b2RIUndjem92TDNSdmEyVnVMbUZqZEdsdmJuTXVaMmwwYUhWaWRYTmxjbU52Ym5SbGJuUXVZMjl0Ck1Gd0dDaXNHQVFRQmc3OHdBUWtFVGd4TWFIUjBjSE02THk5bmFYUm9kV0l1WTI5dEwyTnNhUzlqYkdrdkxtZHAKZEdoMVlpOTNiM0pyWm14dmQzTXZaR1Z3Ykc5NWJXVnVkQzU1Yld4QWNtVm1jeTlvWldGa2N5OTBjblZ1YXpBNApCZ29yQmdFRUFZTy9NQUVLQkNvTUtHWmhaV1l5WkdSa09ERmlNRGN6TmpjME9EUXhNMkUzWXpZME5tTmtNR0ptCll6STJZekF3WVRBd0hRWUtLd1lCQkFHRHZ6QUJDd1FQREExbmFYUm9kV0l0YUc5emRHVmtNQ29HQ2lzR0FRUUIKZzc4d0FRd0VIQXdhYUhSMGNITTZMeTluYVhSb2RXSXVZMjl0TDJOc2FTOWpiR2t3T0FZS0t3WUJCQUdEdnpBQgpEUVFxRENobVlXVm1NbVJrWkRneFlqQTNNelkzTkRnME1UTmhOMk0yTkRaalpEQmlabU15Tm1Nd01HRXdNQ0FHCkNpc0dBUVFCZzc4d0FRNEVFZ3dRY21WbWN5OW9aV0ZrY3k5MGNuVnVhekFaQmdvckJnRUVBWU8vTUFFUEJBc00KQ1RJeE1qWXhNekEwT1RBbUJnb3JCZ0VFQVlPL01BRVFCQmdNRm1oMGRIQnpPaTh2WjJsMGFIVmlMbU52YlM5agpiR2t3R0FZS0t3WUJCQUdEdnpBQkVRUUtEQWcxT1Rjd05EY3hNVEJjQmdvckJnRUVBWU8vTUFFU0JFNE1UR2gwCmRIQnpPaTh2WjJsMGFIVmlMbU52YlM5amJHa3ZZMnhwTHk1bmFYUm9kV0l2ZDI5eWEyWnNiM2R6TDJSbGNHeHYKZVcxbGJuUXVlVzFzUUhKbFpuTXZhR1ZoWkhNdmRISjFibXN3T0FZS0t3WUJCQUdEdnpBQkV3UXFEQ2htWVdWbQpNbVJrWkRneFlqQTNNelkzTkRnME1UTmhOMk0yTkRaalpEQmlabU15Tm1Nd01HRXdNQ0VHQ2lzR0FRUUJnNzh3CkFSUUVFd3dSZDI5eWEyWnNiM2RmWkdsemNHRjBZMmd3VFFZS0t3WUJCQUdEdnpBQkZRUS9ERDFvZEhSd2N6b3YKTDJkcGRHaDFZaTVqYjIwdlkyeHBMMk5zYVM5aFkzUnBiMjV6TDNKMWJuTXZPVEk0T1RBM05UYzFNaTloZEhSbApiWEIwY3k4eE1CWUdDaXNHQVFRQmc3OHdBUllFQ0F3R2NIVmliR2xqTUlHTEJnb3JCZ0VFQWRaNUFnUUNCSDBFCmV3QjVBSGNBM1Qwd2FzYkhFVEpqR1I0Y21XYzNBcUpLWHJqZVBLMy9oNHB5Z0M4cDdvNEFBQUdQeFIxZWhRQUEKQkFNQVNEQkdBaUVBd2VGS3JzSDE2YlA4R21uOExNeXdpOEVhOTZ5aVNLUVpsdUozRzJJUS84QUNJUURPdTViVQpuSGgrZmhIaWt2Uk5tQWNFRmRTSHFrTzJVS052eDF4a01zR1RXVEFLQmdncWhrak9QUVFEQXdOb0FEQmxBakI3CmJKQ3o4U1BlUkIvQlNISUdIeW90akd5RHg4T09JZm5BUG95cGZaVHpBeGtpVzJ6U1pQaDlYMEEzUmhubWZ0Y0MKTVFDbXc2T2xkYW1iK3A3cmROKzk1dk42VTFkT3ZhdDNWTXNpUzQ1b2VMRlZhSW9uOXNickEwSGZGd3RDVUkxZApYRHc9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
      }
    ]
  }
}

If we simplify the integration with Rekor by dropping the DSSE type, and only support hashed rekord, where the rekord would be the DSSE PAE: DSSEv1 + SP + LEN(type) + SP + type + SP + LEN(body) + sp + body (SP is ASCII Space) we actually get some benefits:

1. The signature in the hashed rekord matches the signture put in the DSSE envelope (with pure/non pre hash signature algorithms, need to consider how this would work for such algorithms, can we design this protocol to always sign digests, what would issues be assuming we trust SHA256?)
2. The canonicalization problem of DSSE envelopes goes away (the envelope hash is now part of the Rekor data type).
3. Managing multiple signatures in the DSSE envelope is now trivial:
   • Each signature have an extension where the associated verification material is stored
   • For PQC transition, multiple signatures can be added to the envelope, older clients can still verify using existing signature algorithms
   • As the hashed rekord is the DSSE PAE, the signature of the hashed rekord is the DSSE signature.
4. Rekor is simpler, only a single data type to manage. The response can be greatly simplified by removing the kindVersion field. A lot of code can be dropped from Rekor.
5. The canonicalized body field in Rekor can be removed, we don't need it. Based on the DSSE content, we have all the data to reconstruct each hashed record (the PAE and the siganture).

To get a feel for how this would look, here is an example (with canonicalized body and kind version removed:

{
    "payload": "eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjEiLCJzdWJqZWN0IjpbeyJuYW1lIjoiZ2hfMi41MC4wX21hY09TX2FtZDY0LnppcCIsImRpZ2VzdCI6eyJzaGEyNTYiOiJkMThhY2QzODc0YzliOTE0ZTA2MzFjMzA4ZjhlMjYwOWJkNDU0NTYyNzJiYWNmYTcwMjIxYzQ2Yzc2YzYzNWY2In19XSwicHJlZGljYXRlVHlwZSI6Imh0dHBzOi8vc2xzYS5kZXYvcHJvdmVuYW5jZS92MSIsInByZWRpY2F0ZSI6eyJidWlsZERlZmluaXRpb24iOnsiYnVpbGRUeXBlIjoiaHR0cHM6Ly9zbHNhLWZyYW1ld29yay5naXRodWIuaW8vZ2l0aHViLWFjdGlvbnMtYnVpbGR0eXBlcy93b3JrZmxvdy92MSIsImV4dGVybmFsUGFyYW1ldGVycyI6eyJ3b3JrZmxvdyI6eyJyZWYiOiJyZWZzL2hlYWRzL3RydW5rIiwicmVwb3NpdG9yeSI6Imh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpIiwicGF0aCI6Ii5naXRodWIvd29ya2Zsb3dzL2RlcGxveW1lbnQueW1sIn19LCJpbnRlcm5hbFBhcmFtZXRlcnMiOnsiZ2l0aHViIjp7ImV2ZW50X25hbWUiOiJ3b3JrZmxvd19kaXNwYXRjaCIsInJlcG9zaXRvcnlfaWQiOiIyMTI2MTMwNDkiLCJyZXBvc2l0b3J5X293bmVyX2lkIjoiNTk3MDQ3MTEifX0sInJlc29sdmVkRGVwZW5kZW5jaWVzIjpbeyJ1cmkiOiJnaXQraHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGlAcmVmcy9oZWFkcy90cnVuayIsImRpZ2VzdCI6eyJnaXRDb21taXQiOiJmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwIn19XX0sInJ1bkRldGFpbHMiOnsiYnVpbGRlciI6eyJpZCI6Imh0dHBzOi8vZ2l0aHViLmNvbS9hY3Rpb25zL3J1bm5lci9naXRodWItaG9zdGVkIn0sIm1ldGFkYXRhIjp7Imludm9jYXRpb25JZCI6Imh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpL2FjdGlvbnMvcnVucy85Mjg5MDc1NzUyL2F0dGVtcHRzLzEifX19fQ==",
    "payloadType": "application/vnd.in-toto+json",
    "signatures": [
        {
            "sig": "MEQCIHiO3LhNrbV0Lz7sazQ8a3okIP3DBi45t5oQAQMUV1l/AiBO+NyF4JglqYKPPk2h2tnUFGi37g0wnGUWU/8ihQlOWQ==",
            "extension": {
                "kind": "application/vnd.dev.sigstore.verificationmaterial.v0.1+json",
                "ext":  {
                    "certificate": {
                        "rawBytes": "MIIGjjCCBhSgAwIBAgIUBPAVklFRy1I19DxrL2ppeyAY5rwwCgYIKoZIzj0EAwMwNzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRlcm1lZGlhdGUwHhcNMjQwNTI5MTYwOTQ3WhcNMjQwNTI5MTYxOTQ3WjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYuREZ1X0IP9t7jiECtO5xJxSRty+wPbBIwO8nHIdxfZ+WedgLxwZvFw2X8p6pO0CeQCYvOnOi6AFqsnoZcoF/qOCBTMwggUvMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUV5QyxcivC6bR5crtA0TqKPZ8nskwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4YZD8wWgYDVR0RAQH/BFAwToZMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA5BgorBgEEAYO/MAEBBCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMB8GCisGAQQBg78wAQIEEXdvcmtmbG93X2Rpc3BhdGNoMDYGCisGAQQBg78wAQMEKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwGAYKKwYBBAGDvzABBAQKRGVwbG95bWVudDAVBgorBgEEAYO/MAEFBAdjbGkvY2xpMB4GCisGAQQBg78wAQYEEHJlZnMvaGVhZHMvdHJ1bmswOwYKKwYBBAGDvzABCAQtDCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMFwGCisGAQQBg78wAQkETgxMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA4BgorBgEEAYO/MAEKBCoMKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwHQYKKwYBBAGDvzABCwQPDA1naXRodWItaG9zdGVkMCoGCisGAQQBg78wAQwEHAwaaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkwOAYKKwYBBAGDvzABDQQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCAGCisGAQQBg78wAQ4EEgwQcmVmcy9oZWFkcy90cnVuazAZBgorBgEEAYO/MAEPBAsMCTIxMjYxMzA0OTAmBgorBgEEAYO/MAEQBBgMFmh0dHBzOi8vZ2l0aHViLmNvbS9jbGkwGAYKKwYBBAGDvzABEQQKDAg1OTcwNDcxMTBcBgorBgEEAYO/MAESBE4MTGh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpLy5naXRodWIvd29ya2Zsb3dzL2RlcGxveW1lbnQueW1sQHJlZnMvaGVhZHMvdHJ1bmswOAYKKwYBBAGDvzABEwQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCEGCisGAQQBg78wARQEEwwRd29ya2Zsb3dfZGlzcGF0Y2gwTQYKKwYBBAGDvzABFQQ/DD1odHRwczovL2dpdGh1Yi5jb20vY2xpL2NsaS9hY3Rpb25zL3J1bnMvOTI4OTA3NTc1Mi9hdHRlbXB0cy8xMBYGCisGAQQBg78wARYECAwGcHVibGljMIGLBgorBgEEAdZ5AgQCBH0EewB5AHcA3T0wasbHETJjGR4cmWc3AqJKXrjePK3/h4pygC8p7o4AAAGPxR1ehQAABAMASDBGAiEAweFKrsH16bP8Gmn8LMywi8Ea96yiSKQZluJ3G2IQ/8ACIQDOu5bUnHh+fhHikvRNmAcEFdSHqkO2UKNvx1xkMsGTWTAKBggqhkjOPQQDAwNoADBlAjB7bJCz8SPeRB/BSHIGHyotjGyDx8OOIfnAPoypfZTzAxkiW2zSZPh9X0A3RhnmftcCMQCmw6Oldamb+p7rdN+95vN6U1dOvat3VMsiS45oeLFVaIon9sbrA0HfFwtCUI1dXDw="
                    },
                    "tlogEntries": [
                        {
                            "logIndex": "97913944",
                            "logId": {
                                "keyId": "wNI9atQGlz+VWfO6LRygH4QUfY/8W4RFwiT5i5WRgB0="
                            },
                            "integratedTime": "1716998987",
                            "inclusionProof": {
                                "logIndex": "93750513",
                                "rootHash": "gMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=",
                                "treeSize": "93750515",
                                "hashes": [
                                    "uCO3hICjSShYg1eSenlwTjKq+JLB3ZCyAlvjnh/3yKE=",
                                    "8KDdwXCQI9jhS7ufVuC2BRnD9yXb5Sfb+aLH8+BuSiQ=",
                                    "JruHw9VeLnhrdEVV5mkJr8r+nZ1xqiAydH5iDPVP5fs=",
                                    "GqhYL9+znswADy/JjZXofHxLmeE37Jx2HLJRGYjKeAA=",
                                    "L7xfPpL8AE9ijsQTZeSX7QcbyCPHSxS7ch8Rc4JJVhQ=",
                                    "DZjlMkk1MuzKvAUiWk9KMj9eQjzPpj5GHG9I2Vp+yaU=",
                                    "Tgve40VPFfuei+0nhupdGpfPPR+hPpZjxgTiDT8WNoY=",
                                    "wV+S/7tLtYGzkLaSb6UDqexNyhMvumHK/RpTNvEZuLU=",
                                    "uwaWufty6sn6XqO1Tb9M3Vz6sBKPu0HT36mStxJNd7s=",
                                    "jUfeMOXQP0XF1JAnCEETVbfRKMUwCzrVUzYi8vnDMVs=",
                                    "xQKjzJAwwdlQG/YUYBKPXxbCmhMYKo1wnv+6vDuKWhQ=",
                                    "cX3Agx+hP66t1ZLbX/yHbfjU46/3m/VAmWyG/fhxAVc=",
                                    "sjohk/3DQIfXTgf/5XpwtdF7yNbrf8YykOMHr1CyBYQ=",
                                    "98enzMaC+x5oCMvIZQA5z8vu2apDMCFvE/935NfuPw8="
                                ],
                                "checkpoint": {
                                    "envelope": "rekor.sigstore.dev - 2605736670972794746\n93750515\ngMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=\n\n— rekor.sigstore.dev wNI9ajBFAiEAu9Z/WsClrI/ejoMeXW9QRkDIMr3mXkzSBHDUjw+onw8CIBp9UrmrSf+rl0cM0Xj3zgqChtfMskkeEhgQ7T7nocF1\n"
                                }
                            }
                        }
                    ],
                    "timestampVerificationData": {}
                }
            }
        }
    ]
}

and the size:

$ wc -c dsse_sig_bundle.json
    5012

As seen by dropping the canonicalized body from Rekor we reduce the size of the "bundle" significantly (the canoncalized body contains B64(PEM(DER(cert)) which adds up a bit).

For a complete example, here is an envelope with multiple signatures:

{
  "payload": "eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjEiLCJzdWJqZWN0IjpbeyJuYW1lIjoiZ2hfMi41MC4wX21hY09TX2FtZDY0LnppcCIsImRpZ2VzdCI6eyJzaGEyNTYiOiJkMThhY2QzODc0YzliOTE0ZTA2MzFjMzA4ZjhlMjYwOWJkNDU0NTYyNzJiYWNmYTcwMjIxYzQ2Yzc2YzYzNWY2In19XSwicHJlZGljYXRlVHlwZSI6Imh0dHBzOi8vc2xzYS5kZXYvcHJvdmVuYW5jZS92MSIsInByZWRpY2F0ZSI6eyJidWlsZERlZmluaXRpb24iOnsiYnVpbGRUeXBlIjoiaHR0cHM6Ly9zbHNhLWZyYW1ld29yay5naXRodWIuaW8vZ2l0aHViLWFjdGlvbnMtYnVpbGR0eXBlcy93b3JrZmxvdy92MSIsImV4dGVybmFsUGFyYW1ldGVycyI6eyJ3b3JrZmxvdyI6eyJyZWYiOiJyZWZzL2hlYWRzL3RydW5rIiwicmVwb3NpdG9yeSI6Imh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpIiwicGF0aCI6Ii5naXRodWIvd29ya2Zsb3dzL2RlcGxveW1lbnQueW1sIn19LCJpbnRlcm5hbFBhcmFtZXRlcnMiOnsiZ2l0aHViIjp7ImV2ZW50X25hbWUiOiJ3b3JrZmxvd19kaXNwYXRjaCIsInJlcG9zaXRvcnlfaWQiOiIyMTI2MTMwNDkiLCJyZXBvc2l0b3J5X293bmVyX2lkIjoiNTk3MDQ3MTEifX0sInJlc29sdmVkRGVwZW5kZW5jaWVzIjpbeyJ1cmkiOiJnaXQraHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGlAcmVmcy9oZWFkcy90cnVuayIsImRpZ2VzdCI6eyJnaXRDb21taXQiOiJmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwIn19XX0sInJ1bkRldGFpbHMiOnsiYnVpbGRlciI6eyJpZCI6Imh0dHBzOi8vZ2l0aHViLmNvbS9hY3Rpb25zL3J1bm5lci9naXRodWItaG9zdGVkIn0sIm1ldGFkYXRhIjp7Imludm9jYXRpb25JZCI6Imh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpL2FjdGlvbnMvcnVucy85Mjg5MDc1NzUyL2F0dGVtcHRzLzEifX19fQ==",
  "payloadType": "application/vnd.in-toto+json",
  "signatures": [
    {
      "sig": "MEQCIHiO3LhNrbV0Lz7sazQ8a3okIP3DBi45t5oQAQMUV1l/AiBO+NyF4JglqYKPPk2h2tnUFGi37g0wnGUWU/8ihQlOWQ==",
      "extension": {
        "kind": "application/vnd.dev.sigstore.verificationmaterial.v0.1+json",
        "ext": {
          "certificate": {
            "rawBytes": "MIIGjjCCBhSgAwIBAgIUBPAVklFRy1I19DxrL2ppeyAY5rwwCgYIKoZIzj0EAwMwNzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRlcm1lZGlhdGUwHhcNMjQwNTI5MTYwOTQ3WhcNMjQwNTI5MTYxOTQ3WjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYuREZ1X0IP9t7jiECtO5xJxSRty+wPbBIwO8nHIdxfZ+WedgLxwZvFw2X8p6pO0CeQCYvOnOi6AFqsnoZcoF/qOCBTMwggUvMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUV5QyxcivC6bR5crtA0TqKPZ8nskwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4YZD8wWgYDVR0RAQH/BFAwToZMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA5BgorBgEEAYO/MAEBBCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMB8GCisGAQQBg78wAQIEEXdvcmtmbG93X2Rpc3BhdGNoMDYGCisGAQQBg78wAQMEKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwGAYKKwYBBAGDvzABBAQKRGVwbG95bWVudDAVBgorBgEEAYO/MAEFBAdjbGkvY2xpMB4GCisGAQQBg78wAQYEEHJlZnMvaGVhZHMvdHJ1bmswOwYKKwYBBAGDvzABCAQtDCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMFwGCisGAQQBg78wAQkETgxMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA4BgorBgEEAYO/MAEKBCoMKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwHQYKKwYBBAGDvzABCwQPDA1naXRodWItaG9zdGVkMCoGCisGAQQBg78wAQwEHAwaaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkwOAYKKwYBBAGDvzABDQQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCAGCisGAQQBg78wAQ4EEgwQcmVmcy9oZWFkcy90cnVuazAZBgorBgEEAYO/MAEPBAsMCTIxMjYxMzA0OTAmBgorBgEEAYO/MAEQBBgMFmh0dHBzOi8vZ2l0aHViLmNvbS9jbGkwGAYKKwYBBAGDvzABEQQKDAg1OTcwNDcxMTBcBgorBgEEAYO/MAESBE4MTGh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpLy5naXRodWIvd29ya2Zsb3dzL2RlcGxveW1lbnQueW1sQHJlZnMvaGVhZHMvdHJ1bmswOAYKKwYBBAGDvzABEwQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCEGCisGAQQBg78wARQEEwwRd29ya2Zsb3dfZGlzcGF0Y2gwTQYKKwYBBAGDvzABFQQ/DD1odHRwczovL2dpdGh1Yi5jb20vY2xpL2NsaS9hY3Rpb25zL3J1bnMvOTI4OTA3NTc1Mi9hdHRlbXB0cy8xMBYGCisGAQQBg78wARYECAwGcHVibGljMIGLBgorBgEEAdZ5AgQCBH0EewB5AHcA3T0wasbHETJjGR4cmWc3AqJKXrjePK3/h4pygC8p7o4AAAGPxR1ehQAABAMASDBGAiEAweFKrsH16bP8Gmn8LMywi8Ea96yiSKQZluJ3G2IQ/8ACIQDOu5bUnHh+fhHikvRNmAcEFdSHqkO2UKNvx1xkMsGTWTAKBggqhkjOPQQDAwNoADBlAjB7bJCz8SPeRB/BSHIGHyotjGyDx8OOIfnAPoypfZTzAxkiW2zSZPh9X0A3RhnmftcCMQCmw6Oldamb+p7rdN+95vN6U1dOvat3VMsiS45oeLFVaIon9sbrA0HfFwtCUI1dXDw="
          },
          "tlogEntries": [
            {
              "logIndex": "97913944",
              "logId": {
                "keyId": "wNI9atQGlz+VWfO6LRygH4QUfY/8W4RFwiT5i5WRgB0="
              },
              "integratedTime": "1716998987",
              "inclusionProof": {
                "logIndex": "93750513",
                "rootHash": "gMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=",
                "treeSize": "93750515",
                "hashes": [
                  "uCO3hICjSShYg1eSenlwTjKq+JLB3ZCyAlvjnh/3yKE=",
                  "8KDdwXCQI9jhS7ufVuC2BRnD9yXb5Sfb+aLH8+BuSiQ=",
                  "JruHw9VeLnhrdEVV5mkJr8r+nZ1xqiAydH5iDPVP5fs=",
                  "GqhYL9+znswADy/JjZXofHxLmeE37Jx2HLJRGYjKeAA=",
                  "L7xfPpL8AE9ijsQTZeSX7QcbyCPHSxS7ch8Rc4JJVhQ=",
                  "DZjlMkk1MuzKvAUiWk9KMj9eQjzPpj5GHG9I2Vp+yaU=",
                  "Tgve40VPFfuei+0nhupdGpfPPR+hPpZjxgTiDT8WNoY=",
                  "wV+S/7tLtYGzkLaSb6UDqexNyhMvumHK/RpTNvEZuLU=",
                  "uwaWufty6sn6XqO1Tb9M3Vz6sBKPu0HT36mStxJNd7s=",
                  "jUfeMOXQP0XF1JAnCEETVbfRKMUwCzrVUzYi8vnDMVs=",
                  "xQKjzJAwwdlQG/YUYBKPXxbCmhMYKo1wnv+6vDuKWhQ=",
                  "cX3Agx+hP66t1ZLbX/yHbfjU46/3m/VAmWyG/fhxAVc=",
                  "sjohk/3DQIfXTgf/5XpwtdF7yNbrf8YykOMHr1CyBYQ=",
                  "98enzMaC+x5oCMvIZQA5z8vu2apDMCFvE/935NfuPw8="
                ],
                "checkpoint": {
                  "envelope": "rekor.sigstore.dev - 2605736670972794746\n93750515\ngMhRWa9QJ/1Uo9uNTUUXI1yPO+SvNGJNiY+zGBZMdSc=\n\n— rekor.sigstore.dev wNI9ajBFAiEAu9Z/WsClrI/ejoMeXW9QRkDIMr3mXkzSBHDUjw+onw8CIBp9UrmrSf+rl0cM0Xj3zgqChtfMskkeEhgQ7T7nocF1\n"
                }
              }
            }
          ],
          "timestampVerificationData": {}
        }
      }
    },
    {
      "sig": "MEQCAAAA3LhNrbV0Lz7sazQ8a3okIP3DBi45t5oQAQMUV1l/AiBO+NyF4JglqYKPPk2h2tnUFGi37g0wnGUWU/8ihQlOWQ==",
      "extension": {
        "kind": "application/vnd.dev.sigstore.verificationmaterial.v0.1+json",
        "ext": {
          "certificate": {
            "rawBytes": "MIIGjjAAAASgAwIBAgIUBPAVklFRy1I19DxrL2ppeyAY5rwwCgYIKoZIzj0EAwMwNzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRlcm1lZGlhdGUwHhcNMjQwNTI5MTYwOTQ3WhcNMjQwNTI5MTYxOTQ3WjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYuREZ1X0IP9t7jiECtO5xJxSRty+wPbBIwO8nHIdxfZ+WedgLxwZvFw2X8p6pO0CeQCYvOnOi6AFqsnoZcoF/qOCBTMwggUvMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUV5QyxcivC6bR5crtA0TqKPZ8nskwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4YZD8wWgYDVR0RAQH/BFAwToZMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA5BgorBgEEAYO/MAEBBCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMB8GCisGAQQBg78wAQIEEXdvcmtmbG93X2Rpc3BhdGNoMDYGCisGAQQBg78wAQMEKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwGAYKKwYBBAGDvzABBAQKRGVwbG95bWVudDAVBgorBgEEAYO/MAEFBAdjbGkvY2xpMB4GCisGAQQBg78wAQYEEHJlZnMvaGVhZHMvdHJ1bmswOwYKKwYBBAGDvzABCAQtDCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29tMFwGCisGAQQBg78wAQkETgxMaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkvLmdpdGh1Yi93b3JrZmxvd3MvZGVwbG95bWVudC55bWxAcmVmcy9oZWFkcy90cnVuazA4BgorBgEEAYO/MAEKBCoMKGZhZWYyZGRkODFiMDczNjc0ODQxM2E3YzY0NmNkMGJmYzI2YzAwYTAwHQYKKwYBBAGDvzABCwQPDA1naXRodWItaG9zdGVkMCoGCisGAQQBg78wAQwEHAwaaHR0cHM6Ly9naXRodWIuY29tL2NsaS9jbGkwOAYKKwYBBAGDvzABDQQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCAGCisGAQQBg78wAQ4EEgwQcmVmcy9oZWFkcy90cnVuazAZBgorBgEEAYO/MAEPBAsMCTIxMjYxMzA0OTAmBgorBgEEAYO/MAEQBBgMFmh0dHBzOi8vZ2l0aHViLmNvbS9jbGkwGAYKKwYBBAGDvzABEQQKDAg1OTcwNDcxMTBcBgorBgEEAYO/MAESBE4MTGh0dHBzOi8vZ2l0aHViLmNvbS9jbGkvY2xpLy5naXRodWIvd29ya2Zsb3dzL2RlcGxveW1lbnQueW1sQHJlZnMvaGVhZHMvdHJ1bmswOAYKKwYBBAGDvzABEwQqDChmYWVmMmRkZDgxYjA3MzY3NDg0MTNhN2M2NDZjZDBiZmMyNmMwMGEwMCEGCisGAQQBg78wARQEEwwRd29ya2Zsb3dfZGlzcGF0Y2gwTQYKKwYBBAGDvzABFQQ/DD1odHRwczovL2dpdGh1Yi5jb20vY2xpL2NsaS9hY3Rpb25zL3J1bnMvOTI4OTA3NTc1Mi9hdHRlbXB0cy8xMBYGCisGAQQBg78wARYECAwGcHVibGljMIGLBgorBgEEAdZ5AgQCBH0EewB5AHcA3T0wasbHETJjGR4cmWc3AqJKXrjePK3/h4pygC8p7o4AAAGPxR1ehQAABAMASDBGAiEAweFKrsH16bP8Gmn8LMywi8Ea96yiSKQZluJ3G2IQ/8ACIQDOu5bUnHh+fhHikvRNmAcEFdSHqkO2UKNvx1xkMsGTWTAKBggqhkjOPQQDAwNoADBlAjB7bJCz8SPeRB/BSHIGHyotjGyDx8OOIfnAPoypfZTzAxkiW2zSZPh9X0A3RhnmftcCMQCmw6Oldamb+p7rdN+95vN6U1dOvat3VMsiS45oeLFVaIon9sbrA0HfFwtCUI1dXDw="
          },
          "tlogEntries": {},
          "timestampVerificationData": {
            "Rfc3161Timestamps": [
              "MIIVcjADAgEAMIIVaQYJKoZIhvcNAQcCoIIVWjCCFVYCAQMxDzANBglghkgBZQMEAgMFADCCAaQGCyqGSIb3DQEJEAEEoIIBkwSCAY8wggGLAgEBBgQqAwQBMFEwDQYJYIZIAWUDBAIDBQAEQNTMvOf7wS8/8LelD/PrUSO/cGfR1+H5dA9MYTVrMBLegxrUdKE7bCaz4zOKPonx7idKQBAYpuqqDys3GmATUAsCBAJutpEYDzIwMjIxMDE4MDcwMDMxWgEB/6CCARGkggENMIIBCTERMA8GA1UEChMIRnJlZSBUU0ExDDAKBgNVBAsTA1RTQTF2MHQGA1UEDRNtVGhpcyBjZXJ0aWZpY2F0ZSBkaWdpdGFsbHkgc2lnbnMgZG9jdW1lbnRzIGFuZCB0aW1lIHN0YW1wIHJlcXVlc3RzIG1hZGUgdXNpbmcgdGhlIGZyZWV0c2Eub3JnIG9ubGluZSBzZXJ2aWNlczEYMBYGA1UEAxMPd3d3LmZyZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNidXNpbGV6YXNAZ21haWwuY29tMRIwEAYDVQQHEwlXdWVyemJ1cmcxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCYXllcm6gghAIMIIIATCCBemgAwIBAgIJAMHphhYNqOmCMA0GCSqGSIb3DQEBDQUAMIGVMREwDwYDVQQKEwhGcmVlIFRTQTEQMA4GA1UECxMHUm9vdCBDQTEYMBYGA1UEAxMPd3d3LmZyZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNidXNpbGV6YXNAZ21haWwuY29tMRIwEAYDVQQHEwlXdWVyemJ1cmcxDz"
            ]
          }
        }
      }
    }
  ]
}

Public key in the log

We need to add some verification material back to the transparency log entry when the canonicalized body is removed. My suggestion is to strip the public key from the cert, and then compute SHA256 digest of it, and store that in the log.

This removes any log poisoning possibilities via the cert or a raw public key. This will have some consequences for monitoring, but It's solvable. Any clients using Fulcio can monitor Fulcio's CT log for their identity, then monitor Rekor for usages of that associated public key. For clients using long lived key monitoring is trivial.

This has another benefit,if Fulcio implements log poisoning protection, Rekor is unaffected from that (i.e no changes is needed in Rekor), as only the public key matters. As long as a client can find their entries from Fulcio CT and extract the public key, the associated entry in Rekor is possible to find.

[kommendorkapten]

cc @haydentherapper @bobcallaway @woodruffw @steiza @loosebazooka

[steiza]

It is very helpful to see the examples spelled out here!

I think this is a promising capability, but we'd have to think about sequencing. If we're changing the Rekor response, maybe we want that to be part of Rekor v2, but then are we making it a bigger leap for clients to move from Rekor v1 to v2?

Another idea for adoption is what can we move forward - like maybe there's nothing stopping us today from having all Sigstore clients always use the hashrekord Rekor entry type, using the DSSE PAE if needed like you suggest.

And finally, there's still some open questions around verification. sigstore-go verification options are very oriented around one signature that then may have one or more transparency log entries and / or signed timestamps. We can somewhat easily add a threshold requiring multiple signatures, but each signature might have its own options as to what it requires for verification. Or maybe we keep sigstore-go as-is, only verifying one signature at a time, and require you to call it with different trusted roots and verification options that correspond to the single signature that you're verifying (we aren't really solving multi-signature verification policy, but then it could be handled as part of the changes for cosign v3 or v4).

[woodruffw]

Thanks for opening this @kommendorkapten!

I'm personally very compelled by the idea of flattening/eliminating the distinction between the hashedrekord and dsse types and by eliminating the canonicalization problems that come with the DSSE envelope. However, I also have two (three?) main reservations:

• Per @steiza, I think this implicitly adds a threshold scheme to the sigstore "verification materials" concept, even in the simplest case (same identity, just PQ and non-PQ signature). That's not inherently a bad thing but it's pretty different from what every Sigstore client currently expects, so I'd be curious if others have thoughts on this. I think my main concerns there would be that it's (1) hard to do right, and (2) is a general solution to a specific problem (in the sense that thresholds are arbitrary policy mechanisms, but the underlying problem we're trying to solve is same-identity-multiple-signature-schemes).

• I think the complications/changes to the monitoring story here are pretty significant, and might conflict with other plans the Fulcio folks have 😅 -- my understanding is that they've discussed removing Fulcio's CT log entirely, since it's covered transitively by Rekor's log. This would save the Sigstore infrastructure people from having to run two logs with essentially the same information, but would also mean that this proposal would lack the CT log to correlate against.

  (Separately, I think correlating between the CT/Rekor logs has its own risks -- there's essentially a new availability and consensus risk, plus the monitor will need to use the slower read path on Fulcio until (if?) Fulcio also supports tiling. In effect the latter would undo some of the intended monitor performance benefits of tiling in Rekor v2, I think.)

Finally, on a purely logistical level: does this mean we'd want to eventually discourage and deprecate bundle generation (and verification) within various client ecosystems? That would make sense to me, but I assume would be a non-trivial undertaking for a lot of people 🙂.

(For PyPI in particular it actually wouldn't be the hardest thing, since we treat the bundle format as an "intermediate representation" and we can always change that. However, there have been some user requests for us to serve bundles directly.)

[kommendorkapten]

This post contains a lot of independent proposals for sure, they can be broken out into separate work streams, not all of them needs to happen together to see some wins, e.g. the removal of the verification material in Rekor, that can stay but we switch to DSSE + extensions as an example. There are a lot of good comments from @woodruffw and @steiza , I'll go over them tomorrow in detail. Thanks!

[haydentherapper]

Hey all, lots of great discussion! A few thoughts, but as a tl;dr - This would be a significant overhaul not just to Sigstore but to its adopters, so I'm not in support of it at the moment as I don't think a different format is strong enough motivation.

First, DSSE extensions are not fully approved, they're a part of a dev branch - secure-systems-lab/dsse#61. This doesn't mean that we can't explore using them, but it does signal that they're not yet ready for wide adoption. There is no tooling that supports DSSE extensions to my knowledge.

I've mentioned before that I'm not opinionated on formats. If an ecosystem would prefer DSSEs over the bundle format, then let's build tools that can transform one into the other. Within the Sigstore client ecosystem, it should be opinionated though, to avoid every client needing to support N different formats.

It's also worth noting that the bundle format has already been adopted by a number of package registries. That's not to say we couldn't recommend changing, but we'd need a very strong motivation to go through with that work.

I'm not convinced that there is a need for multi-sigs. These introduce verification complexity on mapping verification material to its signature. PQC is not a strong enough motivation for needing multi-sigs. I would greatly prefer that PQC bundles should be entirely independent from classical crypto bundles. We don't need to introduce the complexity of hybrid deployments and hybrid signature schemes, especially at this early stage of experimentation.

Now, speaking with my Rekor maintainer hat on:

Having multiple types is for a couple reasons:

• It simplifies client logic so clients don't have to know the canonicalization scheme.
• It enables the search index, assuming Rekor feeds its requests into it. We intentionally removed the search index from Rekor v2 because it wasn't clear to us how it was being used, beyond just being a useful tool within the supply chain, but we do plan to revisit it. Without the DSSE, all that goes into the search index is an artifact hash and identity, which isn't that valuable.

Early on, we had considered a single request and response type in Rekor v2. We decided to have multiple request types for the reasons above. With v2's responses, they're more-or-less the same - dsse contains an envelope hash, verifier, and signature, and hashedrekord contains a hash, verifier and signature. I'd be open to considering simplifying the response, but I'm not sure it's worth it, because we still need kind/version for Rekor v1 entries, and we may at some point want to add support for more types.

like maybe there's nothing stopping us today from having all Sigstore clients always use the hashrekord Rekor entry type, using the DSSE PAE if needed like you suggest

I agree with this, a client can choose to just ignore the dsse type and use hashedrekord. This might be an issue for client conformance however if one assumes that when given a DSSE, the Rekor type is a DSSE.

my understanding is that they've discussed removing Fulcio's CT log entirely, since it's covered transitively by Rekor's log

Yep, this is strongly in consideration.

[kommendorkapten]

Sorry for a late reply.

Client considerations

This would be a significant overhaul not just to Sigstore but to its adopters

Agreed, I think I wasn't clear that I'm not proposing to do this now, it's in the context of my reflection to the summary you shared in slack over the topics that was discussed at OSS NA a few weeks ago, i.e future looking and commenting on what was discussed and my take on it.

Multi signature

I'm not convinced that there is a need for multi-sigs. These introduce verification complexity on mapping verification material to its signature

With the dsse extension, there would be a 1 to 1 mapping, i.e no complexity as the verification material would be a property of the signature, so there is no confusion on which verification material to use for a signature.

Note

Multi sig bundles as it's formatted today would be a bad idea IMHO, the discussion below is only valid for a dsse + ext scenario.

On the topic of one bundle per signature scheme, or one bundle with multiple signatures, I would argue that the the client complexity would be the same.

With one bundle, a verifier need to introspect the bundle and apply its policy (e.g. one signature from a trusted entity is enough, using a PQC scheme).

With multiple bundles, the verifier needs load its policy, to fetch multiple bundles, iterate over them until a trusted signature is found (and e.g. using a PQC scheme). For the complete operation, we can not just look at the verification steps for one bundle, IMHO we must take into consideration bundle discovery and processing too.

For TSA and TLog we support multiple entries in the bundle too, and I don't remember that causing any issues. With a single bundle, I would think that discovery and processing becomes a tiny bit easier. This is not a hill I'm ready to die on, but I have a slight preference for multi sig bundles here (if dsse + ext becomes a thing).

Rekor multiple types

It simplifies client logic so clients don't have to know the canonicalization scheme.

I think we can reason about this in a different way. Today we have two types (hr and dsse). If we simplify Rekor to only support hr, we can define the canonicalization scheme for popular data types (i.e. dsse) and let each client implement them and expose a method for it. This logic already ought exist in client to be able to verify the canonicalized response. So with client canonicalization reach the same the same goal in practice (the sigstore client library provides the necessary canonicalization method to the client to use before publish), but can simplify the bundle format and Rekor's implementation. And this would also let us remove the canonicalized resoonse in the bundle's tlog entry (we tried to remove this response in the first phase as it's duplicated data and it's pretty big in terms of size).

The risk here is broken canonicalization by clients. For dsse, this can be tested by sigstore conformance test suite to provided clients with good test vectors.

CT and Tlog / log poisoning

my understanding is that they've discussed removing Fulcio's CT log entirely, since it's covered transitively by Rekor's log

Yep, this is strongly in consideration.

I was not aware of this, is there any place where things like this are discussed, and ideas for log poison prevention? Simplifying this is a good idea as I think there is some overlap/confusion in reality for users on this 👍