9:17 a.m.
On Thu, Mar 13, 2014 at 2:16 PM, Bruno Oliveira <bruno(a)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(a)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(a)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