Cryptographic Suites vs. Keys (was: Re: DID Spec Closure Process: Harmonize our two Cryptographic Key Material Proposals?)

On 12/27/2017 02:16 AM, =Drummond Reed wrote:
> 1. It would allow developers or applications who prefer "naive JSON"
>  to use the DID document for basic key management with a simple array
>  of keys described by type.

Building on what Joe, Pelle, and I seem to agree on, let's dive into
what goes into the "auth" field that Joe's suggesting. Once again, I'm
not going to mention RDF or JSON-LD at all because this thread has
almost nothing to do with graph-based vs. tree-based representations.

So, we start out with this:

{
  "auth": [ ... ]
}

... and the question is, what goes in that array? We have two proposals
at this point in time:

P1. An array of keys.
P2. An array of authentication suites.

In proposal #1 above, a key would be expressed like so:

"keys": [{
  "id": "#key1",
  "type": "rsa-signing-2017-pem",
  "value": "-----BEGIN KEY...END KEY-----\r\n"
}]

The proposal above has the following limitations:

L1. There is only ONE representation for the key even though many
    /standardized/ variations exist in the wild.
L2. The application/purpose of the key is not specified.
L3. It's not clear how biometrics are supported.
L4. Different limitations cannot exist independently for different
    application/purposes of the key. For example, 2KB key required for
    authentication but 4KB required for signing contracts.
L5. Full algorithm agility may be supported, which is very dangerous.

In proposal #2 above, an authentication suite could be expressed like so:

"auth": [{
  "id": "#auth1",
  "type": "RsaKeyBasedAuthentication2017",
  "publicKey": {
    "id": "#key1",
    "type": "RsaSigningKey2017",
    "owner": "did:example:0123456789abcdef",
    "publicKeyPem": "-----BEGIN KEY...END KEY-----\r\n",
    "publicKeyJwk": {...}
  }
}]

This addresses all of L1-L5 above:

L1. Multiple representations are supported (e.g. PEM /and/ JWK).
L2. Application purpose is clear via "auth" and
    "RsaKeyBasedAuthentication2017".
L3. Biometrics are supported via specification of different
    Authentication Suites.
L4. Different suite limitations can be specified
    (e.g. "RsaKeyBasedAgreement2017", which would require 4KB key size)
L5. Suite limitations limit algorithm agility by design, ensuring that
    implementations are easier to test from a security perspective.

The only weakness shared with both proposals is that if you were to just
extract the key material, you would lose the application/purpose of the
key. The only way to prevent that from happening is to repeat the data
in the key description itself, which isn't terrible, but not great either.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/

Received on Wednesday, 3 January 2018 20:26:43 UTC