Re: JWS & GPG Signature Suites for 2020

BTW, are you aware that all GitHub registered public GPG keys are available
at https://github.com/<githubuserid>.gpg — for instance mine is at
https://github.com/ChristopherA.gpg

I too have been thinking about doing some JSON-LD signature as a GPG
detached signature where the public key is at a URL like this. Useful
particularly for did:git, did:github and maybe some form of did:peer.

If I do have to figure out how to rotate my widely available GPG key — had
to extend my expiration date last year due to GPG keyserver denial attacks.

— Christopher Allen [via iPhone]



On Sun, Feb 16, 2020 at 2:41 PM Orie Steele <orie@transmute.industries>
wrote:

> Friends,
>
> Due to regulatory and hardware limitations, we've developed 2 new linked
> data signature suites:
>
> Web Crypto supports non extractable keys, and Azure Key Vault, and other
> KMS support hardware backed KMS operations for NIST Curves, yet there were
> no linked data signature suite available.
>
> We created:
>
> - https://github.com/transmute-industries/lds-jws2020
>
> To support developers who need to work with P-256 / P384 / RSA, when
> ed25519 or secp256k1 are not allowed or supported in hardware / software.
> It relies on publicKeyJwk JWK keys.
>
> We also love GPG and have released:
>
> - https://github.com/transmute-industries/lds-gpg2020
>
> This suite supports GPG in browser, locally using GPGSuite for mac / gpg2
> for linux etc.... and also GPG card integrations with things like Yubikey.
> It relies on publicKeyGpg ascii armored keys.
>
> GPG is widely used to sign git commits, or software such as TOR and Tails
> binaries... now you can use your same (but you shouldn't ever do this) GPG
> keys to create Linked Data Signatures, and verifiable credentials using
> decentralized identifiers.
>
> Both libraries can be used with
> https://github.com/digitalbazaar/jsonld-signatures and
> https://github.com/digitalbazaar/vc-js.
>
> Both libraries support the following key types: ed25519, secp256k1, rsa,
> p-256, p-384, p-521.
>
> We have already had some lively discussion about "algorithmic agility
> being an anti-pattern" here:
> https://github.com/transmute-industries/lds-jws2020/issues/4
>
> We'd like to register these suites here:
> https://github.com/w3c-ccg/security-vocab
>
> In order to do that, we have defined the necessary documentation for both:
>
> {
>   "id": "https://gpg.jsld.org/contexts/#GpgSignature2020",
>   "type": "SignatureSuite",
>   "canonicalizationAlgorithm": "https://w3id.org/security#URDNA2015",
>   "digestAlgorithm": "
> https://www.ietf.org/assignments/jwa-parameters#SHA256",
>   "signatureAlgorithm": "https://tools.ietf.org/html/rfc4880#section-11.4"
> }
>
> {
>   "id": "https://lds.jsld.org/contexts/#JsonWebSignature2020",
>   "type": "SignatureSuite",
>   "canonicalizationAlgorithm": "https://w3id.org/security#URDNA2015",
>   "digestAlgorithm": "
> https://www.ietf.org/assignments/jwa-parameters#SHA256",
>   "signatureAlgorithm": "https://tools.ietf.org/html/rfc7518"
> }
>
> We'd love feedback, feel free to fork our implementation and restrict the
> key types to a single value and define a new signature suite for that
> single key type, for each of the supported key types and signature
> algorithms.
>
> In order to register these, it appears it may be time to create
> https://w3c-ccg.github.io/security-vocab/contexts/security-v3.jsonld
>
> We'd like to fix all the remaining documentation issues associated with
> w3id.org/security, before adding more properties.... Please see
> https://github.com/w3c/did-core-registry/issues/3 as this related to the
> did wg.
>
> We are offering to make these vocabulary updates for the community, please
> let us know how we can proceed.
>
>
> OS
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>