Let me try to answer your questions so I can see if I have understand it well and then Abstractj can confirm (or not ) :) 


On Mon, Mar 10, 2014 at 10:01 PM, Matthias Wessendorf <matzew@apache.org> wrote:
Ahoy!


On Mon, Mar 10, 2014 at 9:49 PM, Bruno Oliveira <abstractj@redhat.com> wrote:
Good morning guys, for this issue https://issues.jboss.org/browse/AGPUSH-358. 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?

1. Each application has its own key pair

each of the PushApplication constructs/objects on the UPS ? 
Yes, What I understand : each PushAPP has his own pair 
 
2. Before the addition of the iOS variant, the client sends a request asking for the public keys

"the client" ? Is that the AdminUI (or the relevant HTTP Rest code), when someone clicks "Add new Variant" ? 
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. 

 
3. The server sends an HTTP response with the public key for encryption
4. The client make use of the public key to encrypt the certificate + the passphrase
5. Server stores it encrypted
6. When necessary to send push messages, the server make use of the private key to decrypt that data and send fancy messages.

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" ? 
I don't think so since it will use only the private key to decrypt, so the API stays unchanged. 
 

Does it make sense to you?

Somewhat - not sure I fully understood :) 
 

--
abstractj

JBoss, a division of Red Hat



_______________________________________________
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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev