dsse

FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment. One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think. Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4] [1] https://datatracker.ietf.org/group/scitt/about/ [2] https://www.nist.gov/itl/executive-order-14028-improving-nat... [3] https://github.com/secure-systems-lab/dsse [4] https://www.rfc-editor.org/rfc/rfc8152 [5] https://github.com/in-toto/attestation

I took a look at the design and think there are a few issues with the format as proposed. # The public key is stored with the signature. This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys. # The algorithm is stored with the signature. This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35 I didn't look at the sub-key protocol in detail. The ephemeral key for e