<div dir="ltr">Let me try to answer your questions so I can see if I have understand it well and then Abstractj can confirm (or not ) :) <div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 10:01 PM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ahoy!<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Mar 10, 2014 at 9:49 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:abstractj@redhat.com" target="_blank">abstractj@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Good morning guys, for this issue <a href="https://issues.jboss.org/browse/AGPUSH-358" target="_blank">https://issues.jboss.org/browse/AGPUSH-358</a>. I was revisiting the whole UPS code and thinking about include two fields for iOSVariant class: skey (secret key) and pKey (public key). What’s the idea?<br>
<br>
1. Each application has its own key pair<br></blockquote><div><br></div></div><div>each of the PushApplication constructs/objects on the UPS ? </div></div></div></div></blockquote><div>Yes, What I understand : each PushAPP has his own pair </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Before the addition of the iOS variant, the client sends a request asking for the public keys<br></blockquote><div><br></div></div><div>"the client" ? Is that the AdminUI (or the relevant HTTP Rest code), when someone clicks "Add new Variant" ? </div>
</div></div></div></blockquote><div>I understand the AdminUI/Rest Service. And this mean there will be an extra REST service to retrieve the public key. Idea : maybe the public key could be already in the response of the GET of the "Parent" PushApplication. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. The server sends an HTTP response with the public key for encryption<br>
4. The client make use of the public key to encrypt the certificate + the passphrase<br>
5. Server stores it encrypted<br>
6. When necessary to send push messages, the server make use of the private key to decrypt that data and send fancy messages.<br></blockquote><div><br></div></div><div>Now, when a (JavaEE) application is sending a request for push messages to the UPS (which than internally makes use of the private key to decrypt that data and send fancy messages to Apple), the HTTP RestEndpoint requires a new argument (the public key) to be allowed to submit these "requests" ? </div>
</div></div></div></blockquote><div>I don't think so since it will use only the private key to decrypt, so the API stays unchanged. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Does it make sense to you?<br></blockquote><div><br></div></div><div>Somewhat - not sure I fully understood :) </div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
--<br>
abstractj<br>
<br>
JBoss, a division of Red Hat<br>
<br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all">
<div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div></div>