W3C home > Mailing lists > Public > public-credentials@w3.org > February 2020

JWS & GPG Signature Suites for 2020

From: Orie Steele <orie@transmute.industries>
Date: Sun, 16 Feb 2020 16:39:40 -0600
Message-ID: <CAN8C-_JVwzr71O7J9EfAbRuRf8ZziV8XxsM8MnLv8sFLQVO23w@mail.gmail.com>
To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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>
Received on Sunday, 16 February 2020 22:40:06 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 16 February 2020 22:40:06 UTC