|
|
|
|
|
|
by trishankdatadog
1116 days ago
|
|
|
python-tuf [1] back then assumed that everything was manipulated locally, yes, but a lot has changed since then: you can now read/write metadata entirely in memory, and integrate with different key management backend systems such as GCP. More importantly, I should point out that while Sigstore's Fulcio will help with key management (think of it as a managed GPG, if you will), it will not help with securely mapping software projects to their respective OIDC identities. Without this, how will verifiers know in a secure yet scalable way which Fulcio keys _should_ be used? Otherwise, we would then be back to the GPG PKI problem with its web of trust. This is where PEP 480 [2] can help: you can use TUF (especially after TAP 18 [3]) to do this secure mapping. Marina Moore has also written a proposal called Transparent TUF [4] for having Sigstore manage such a TUF repository for registries like PyPI. This is not to mention the other benefits that TUF can give you (e.g., protection from freeze, rollback, and mix-and-match attacks). We should definitely continue discussing this sometime. [1] https://github.com/theupdateframework/python-tuf [2] https://peps.python.org/pep-0480/ [3] https://github.com/theupdateframework/taps/blob/master/tap18... [4] https://docs.google.com/document/d/1WPOXLMV1ASQryTRZJbdg3wWR... |
|
|
W3C ReSpec: https://github.com/w3c/respec/wiki
blockcerts-verifier (JS): https://github.com/blockchain-certificates/blockcerts-verifi...
blockchain-certificates/cert-verifier (Python): https://github.com/blockchain-certificates/cert-verifier
https://news.ycombinator.com/item?id=35896445 :
> Can SubtleCrypto accelerate any of the W3C Verifiable Credential Data Integrity 1.0 APIs? vc-data-integrity: https://w3c.github.io/vc-data-integrity/ ctrl-f "signature suite"
>> ISSUE: Avoid signature format proliferation by using text-based suite value The pattern that Data Integrity Signatures use presently leads to a proliferation in signature types and JSON-LD Contexts. This proliferation can be avoided without any loss of the security characteristics of tightly binding a cryptography suite version to one or more acceptable public keys. The following signature suites are currently being contemplated: eddsa-2022, nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, and jws-2022.