search

pki-io / core

Main pki.io repo
Other
31 stars 7 forks source link

Switch to JWS and JWE #36

Open kalloc opened 9 years ago

kalloc commented 9 years ago

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 commented 9 years ago

+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 https://github.com/pki-io/pki.io/issues/36#issuecomment-72287608.

thanasisk commented 9 years ago

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 commented 9 years ago

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

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 commented 9 years ago

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 https://github.com/pki-io/pki.io/issues/36#issuecomment-72618588.

zeroXten commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

jonbonazza commented 9 years ago

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 commented 9 years ago

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 https://github.com/pki-io/pki.io/issues/36#issuecomment-72696930.

zeroXten commented 9 years ago

Moving to read as not assigned to anyone.