Switch to JWS and JWE

[kalloc]

No description provided.

[kalloc]

If we going to use json, we can use json compactibility standard
JWE for encryption - https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
and
JWS for transport and export — https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41

[jonbonazza]

+1 for the use of JWE and JWS, except I propose we also support using EC
keys aong with RSA keys and thus also support ECIES encryption.

On Fri Jan 30 2015 at 3:16:42 PM kalloc notifications@github.com wrote:

If we going to use json, we can use json compactibility standard
JWE for encryption -
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
and
JWS for transport and export —
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41

—
Reply to this email directly or view it on GitHub
#36 (comment).

[thanasisk]

Looks like a good idea but I would like to play devil's advocate here: Are these not still in draft mode - meaning they are liable to change?

[zeroXten]

So is the idea to use those for encrypting/signing pki.io specific JSON objects? Basically using them as the containers (document.container)? If so, they'd need to support

• Authentication using a HMAC (used as part of the pairing process when keys haven't been fully distributed yet)
• Group encryption. A single document would need to be encrypted for multiple recipients. For example, the Org entity private keys are encrypted for each of the Org-level admins, so the admins can decrypt the Org entity private keys and operate on behalf of the Org entity.
• It would be amazing if JWE supported split-key encryption :D The idea being to split-key encrypt the Root private keys so that decrypting them requires e.g. 2 out of 3 admins.

I personally wouldn't be too worry about them being draft. We can double check things, but half of the Internet is based on things in draft, and at least they're unlikely to change frequently compared to packages we depend on.

[jonbonazza]

Tge way i understand it is jwe/jws are used for the secure transport of
json over a non-tls connection. Unless i am misunderstanding something.

On Tue, Feb 3, 2015, 1:24 AM Fraser Scott notifications@github.com wrote:

So is the idea to use those for encrypting/signing pki.io specific JSON
objects? Basically using them as the containers (document.container)? If
so, they'd need to support

• Authentication using a HMAC (used as part of the pairing process
  when keys haven't been fully distributed yet)
• Group encryption. A single document would need to be encrypted for
  multiple recipients. For example, the Org entity private keys are encrypted
  for each of the Org-level admins, so the admins can decrypt the Org entity
  private keys and operate on behalf of the Org entity.
• It would be amazing if JWE supported split-key encryption :D The
  idea being to split-key encrypt the Root private keys so that decrypting
  them requires e.g. 2 out of 3 admins.

I personally wouldn't be too worry about them being draft. We can double
check things, but half of the Internet is based on things in draft, and at
least they're unlikely to change frequently compared to packages we depend
on.

—
Reply to this email directly or view it on GitHub
#36 (comment).

[zeroXten]

hmm, have to be careful here with the difference between securing data at rest vs data in motion. I presume the json stuff works on data at rest, so hybrid encryption of documents. This can be used of course to secure the data in the absence of TLS, but you wouldn't get PFS because of its asynchronous nature. This is then solving the same problem as I have done with the document.containers.

If it is somehow designed as a data-in-motion alternative to TLS, then it might have properties that make it unsuitable for data-at-rest. I guess a bit of reading it to it would be good, but I'm going to continue my focus on the workflows. We can switch later if that suites us.

[kalloc]

We want transport between nodes.
It's a good idea to make CMS for container, but CMS is hard and my vote for JWS.
It will allow to transport message by mail or any other offline methods.
We can use TLS, jws isn't replacement for SSL/TLS

[kalloc]

I understand, this is draft, but it's prefer than new standard (if we will not make new one)

[jonbonazza]

Looking at this again, it seems to be transport security, so it makes more sense to utilize ECDH than ECIES. ECDH is already recommended for JWS/JWE implementations as per the JWA RFC, so I don't think there is an issue there. ECDH is a key agreement protocol.

[jonbonazza]

I suppose, then, I am misunderstanding the purpose of JWE/JWS. To me, it
seems like a way of transporting encrypted data in a json format without
having to use TLS.The mention of offline transport is interesting, as some
of the algorithms specified in the RFC do not support offline comms (e.g.
ECDH).

On Tue Feb 03 2015 at 9:39:42 AM kalloc notifications@github.com wrote:

I understand, this is draft, but it's prefer than new standard (if we will
not make new one)

—
Reply to this email directly or view it on GitHub
#36 (comment).

[zeroXten]

Moving to read as not assigned to anyone.