Re: WebKMS and Serialization

Thanks @Daniel, this kind of alignment is what we're looking for...

At IIW, we talked a little bit about the mixed case wallet / keystore,
where you might have some extractable keys, some non extractable in browser
keys, some keys in an enterprise KMS (both extractable and not).

As a developer, I want a way to serialize the concept of these keys and
associated metadata even if I can't actually serialize the plaintext
private keys.

We used the term virtual wallet file to describe this concept at one point
but when we found out about WebKMS, we were hoping someone else would solve
this for us :)

As I understand WebKMS today, it would be possible to do the following and
preserve our browser based demos:

1. Generate and Export JWK
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/exportKey /
Use standalone libraries to do the same.
2. Annotate JWKS in some to be determined way. (according to what standard?)
3. Import Annotated JWKS into WebKMS Driver for Browser / Mobile / Server
4. Use WebKMS interface in application for DID related key operations...
5. Transparently migrate to another WebKMS Driver while preserving app
functionality by leveraging the WebKMS interface.

I may not be using the right WebKMS terminology here, important to note
that for crypto that is not natively supported, the driver would need
plugins for keys that it might not normally be able to create signatures
from, such as ed25519 and secp256k1.

I think we could actually support more than one annotated keystore
serialization, but we need at least one first.

Looking at indy-sdk-wallet-import-export
<https://github.com/hyperledger/indy-sdk/tree/master/docs/design/009-wallet-export-import>,
there are some immediately obvious metadata properties, such as
unstructured string array "tags"... we are currently abusing this property
to its fullest in our implementation :)

It appears that there is already a JSON serialization of the current indy
sdk wallet files, could we see some examples of encrypted and
unencrypted wallet files?

My guess is that with the addition of JSON Schema or JSON-LD, we could
easily annotate the plaintext JSON wallet file, and create some kind of
interoperable standard for the simple case.

If I can figure out how to do that in such a way that allows us to use
wallet files that are indy-sdk compliant I can drop our did-wallet
hackyness, and together we can maybe standardize the simple case before
tackling the harder case of remote / non extractable keys... of course I
will need to be able to get the plaintext wallet file in the browser...
does this work today, are there any references? If not, it's possible we
can build this together along with the browser web kms driver in such a way
that it will work for indy-sdk out of the box...

OS


ᐧ

On Mon, Jan 6, 2020 at 12:47 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> There are two levels of interoperable data we ought to think about: what
> does plaintext serialized data look like, and what does
> encrypted/compressed serialized data look like.
>
> Plaintext wallet data in codebases that use Hyperledger Indy (libindy.so)
> is MessagePacked and consists of records that are very simple: name (a
> string identifier), type (a short token; can't remember if it's an int or a
> few chars), value (BLOB or MEMO-type field, IIRC), value_key (crypto key).
> I can't remember if value_key is preserved on export or thrown away to be
> rebuilt on import. Encrypted wallet data in codebases that use Hyperledger
> Indy uses a streaming cipher (ChaCha20-Poly1305-IETF, IIRC); see these
> design docs
> <https://github.com/hyperledger/indy-sdk/tree/master/docs/design/009-wallet-export-import>.
> I've added a couple EV people to the thread who know more than I do about
> it. We felt that streaming was important, as some enterprise wallets might
> contain millions of keys, even though the wallets on mobile apps are far
> smaller. Theoretically this results in a standard, portable package where
> the data could be reimported anywhere; however, we've found a couple
> caveats as some impls add a compression packaging that others lack. This
> approach has certain virtues, but is not without drawbacks, too.
>
> I think people in Indy's or Aries's orbit would be happy to tweak our
> approach, or share it, to find common ground. Making this data portable is
> an important proof-point for self-sovereignty; we don't want vendor wallet
> data lock-in.
>
> On Mon, Jan 6, 2020 at 10:57 AM Orie Steele <orie@transmute.industries>
> wrote:
>
>> Happy New Year!
>>
>> We've updated our did:key demo to point to the did:key method spec, and
>> work with our test web wallet serialization format we use in did:github and
>> did:elem.
>>
>> https://did-key.web.app/ (Open Source)
>>
>> We're working towards an encrypted data vaults demo that works with
>> did:key, did:github and did:elem.
>>
>> One of the challenges we are facing along the way is getting keys and
>> meta data from our existing "wallet" system into the software needed to
>> connect to an encrypted data vault, which is used by
>> https://github.com/digitalbazaar/edv-client
>>
>> Because much of the crypto we use (secp256k1 and ed25519) don't have
>> built in browser support, we are forced to use extractable keys, and in
>> browser crypto suites such as lib sodium.
>>
>> This causes us to often need to import key material and meta data into a
>> browser or client app, for demo purposes... we created this test javascript
>> / json (wallet/keystore) serialization library to help do this:
>>
>> https://github.com/transmute-industries/did-wallet
>>
>> Increasingly we're finding ourselves storing DID meta data in these
>> wallet files in order to work with demos for encrypted data vaults /
>> ZCaps...
>>
>> In other words, our portability system for keys is starting to overlap a
>> bit with WebKMS... https://digitalbazaar.github.io/webkms/
>>
>> We don't want to be going our own way here, we want our portability
>> solution to be WebKMS compliant, and from what I understand, it would not
>> be that hard to get there.
>>
>> What we need is a standard way of describing a set of keys (including
>> private keys), and a set of metadata about those keys in a way that can be
>> serialized to a string and encrypted... (this is what our existing
>> did-wallet does, it's not fancy).
>>
>> My question to this group is: *What is the standard for serializing a
>> collection of key material and metadata that best integrates with web kms,
>> if there is not one, how might we go about defining such a thing?*
>>
>> I will note that JWKS is a solution to this problem, but it's not obvious
>> that adding metadata fields to a JWK would be how the community would want
>> to solve this issue... and I think the metadata would need some type /
>> semantic information such as JSON-LD or JSON Schema to be useful.
>>
>> Regards,
>>
>> OS
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>> ᐧ
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>