On Thu, Mar 13, 2014 at 2:16 PM, Bruno Oliveira <bruno@abstractj.org> 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 

 

Other answers inline.

--
abstractj

On March 13, 2014 at 10:02:04 AM, Matthias Wessendorf (matzew@apache.org) wrote:
> On Thu, Mar 13, 2014 at 12:59 PM, Bruno Oliveira wrote:
> > iOS Variant:
> >
> > - HTTP request
> >
> > Remain unchanged, but now certificate and passphrase can be send
> > encrypted and the server will store it.
> >
>
>
> encrptyed w/ the help of the public-key ?

Totally correct


Ok, good. Oh, question: do we provide a tool for the encryption? 
 

>
>
>
>
> >
> > - HTTP response
> >
> > Remain unchaged
> >
> > Sender:
> >
> > - HTTP request
> >
> > Remain unchanged,
>
>
>
> w/ "unchanged" you basically mean the payload of the "Send request" is the
> same as it is today, right ?

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 :)

 

>
>
>
> > but now the server will search for the application ID and retrieve the
> > public key to decrypt application's passphrase
> >
>
>
> Ok, that's internal details. So the server basically deprcypts both: cert
> and its passphrase, in order to establish the connection to APNs

Correct

cool

 

> >
> >
> > AeroGear Clients
> >
> > - cURL
> >
> > Yesterday I had the amusing experience of dig into the sources of OpenSSL
> > and their documentation, to see how people could encrypt it from the
> > command line. If I recommend that people would remember my name for the
> > eternity in a bad way. Another insane idea was to provide encoders for GPG.
> > The simplest idea, I think, would be provide code for people encrypt their
> > passphrase and certificate, instead of trust in some software.
> >
>
> but that's really just for the "registration part", right ? I don't care
> that much about a cumbersome API there :-) Because in 99% of all cases the
> actual registration (and cert/passphrase upload) is done via the sexy Admin
> UI.
>
>
> The CURL for the send stays the same as it is today, right ?

Correct. The sexy admin UI is not really a concern to me, but the clients external to it.

and external clients are in 99% of the cases just using SEND - not the Registration bits
 
The goal is mostly provide options for people encrypt their thing.

yep!! And that is great!
 

> >
>
>
> It looks like it goes towards the right direction!
>
> Thanks for looking into it
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev




--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf