Re: [aerogear-dev] Passphrase encryption - REST API discussion

Nailed it, you understanding is correct

-- abstractj On Thu, Mar 13, 2014 at 11:53 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Thu, Mar 13, 2014 at 3:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > >> nswers inline. >> >> -- >> abstractj >> >> On March 13, 2014 at 10:29:48 AM, Matthias Wessendorf (matzew(a)apache.org) >> wrote: >> > On Thu, Mar 13, 2014 at 2:16 PM, Bruno Oliveira wrote: >> > >> > > Ahoy, regarding the HTTP header we can move it to the body. What >> would you >> > > suggest? >> > > >> > >> > No, I'd like to avoid that protected header/body at all :-) >> > >> > But... if the server really can not figure out if cert. and its >> passphrase >> > are encrypted, I guess I can live w/ it - for now. >> > Ideally the SEND API stays unchanged >> >> We can if we add one step further. Let me put the new idea in a gist ( >> https://gist.github.com/abstractj/55905ed53fce2ca22388). >> >> If developer requested a key pair, we create a new one for that >> PushApplicationID and check it on Sender if exists a key pair for that >> application. Into this way we make encryption totally optional. >> >> Does it make sense? >> > > Not sure I fully understand - let's see :) > > Steps (the encryption case): > 1) create/register Push Application > 2) request the optional publicKey > 3) use the public key (w/ some tool) to encrtypt the certificate together > with its passphrase > 4) on iOS variant, I provide the encrypted certificate and the encrypted > passphrase > 5) For sending: use the same CURL as today - internally it checks: Does > pushApp contain publicKey - if YES, do the decryption dance; > > > So that basically means: if I execute 2) (request the publicKey), > submitting encrypted certificate/passphrase is now required > > So, yeah that sounds good to me > > >> >> > > > >> > > > encrptyed w/ the help of the public-key ? >> > > >> > > Totally correct >> > > >> > >> > Ok, good. Oh, question: do we provide a tool for the encryption? >> >> Sure thing, I'm all for make it easy. >> > > > > yay! > > > >> >> > > Correct. But with we agree on the flag, might be necessary to include >> > > something like "protected: true" as optional argument. Or any other >> thing >> > > to let the server know. >> > > >> > >> > yeah, I see. Hrm - not sure I like the flag :-) >> > Perhaps there is a way (at least for the "long run") that the server >> gets: >> > Ah, it is encrypted (or not). >> > >> > As said the flag is not the end of the world - I just try to make the >> > "SEND" as simple as possible :) >> >> If we agree on that gist, we don't need this flag anymore. >> >> Let me know what do you guys think about the idea. >> > > I *think* it sounds good ;-) > > -Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >