Nailed it, you understanding is correct

—
abstractj

On Thu, Mar 13, 2014 at 11:53 AM, Matthias Wessendorf <matzew@apache.org> wrote:

On Thu, Mar 13, 2014 at 3:18 PM, Bruno Oliveira <bruno@abstractj.org> wrote:

nswers inline.

-- 
abstractj

On March 13, 2014 at 10:29:48 AM, Matthias Wessendorf (matzew@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