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

2. Before the addition of the iOS variant, the client sends a request asking for the public keys

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.

Does it make sense to you?

-- abstractj JBoss, a division of Red Hat _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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 wrote: > Ahoy! > > > On Mon, Mar 10, 2014 at 9:49 PM, Bruno Oliveira 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(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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Ahoy, answers inline. -- abstractj On March 10, 2014 at 6:01:33 PM, Matthias Wessendorf (matzew(a)apache.org) wrote: > Ahoy! > > > On Mon, Mar 10, 2014 at 9:49 PM, Bruno Oliveira 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 if that makes sense to the others like Android variants. And no if we just want to use it with iOSVariant, into this case that would apply only for iOS applications.

> > > > 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" ? Whatever REST consumer we have or the service. > > > > > 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" ? On the client side, after the public key retrieval you don't need to add new parameters. As Sebastien mentioned it would remain unchanged.

Currently: curl -3 -v -b cookies.txt -c cookies.txt -i -H "Accept: application/json" -H "Content-type: multipart/form-data" -F "certificate=(a)/Users/matzew/Desktop/MyProdCert.p12" -F "passphrase=TopSecret" -F "production=true" // make sure you have Production certificate and Provisioning Profile -X POST https://SERVER:PORT /CONTEXT/rest/applications/{pushApplicationID}/iOS Proposed: curl -3 -v -b cookies.txt -c cookies.txt -i -H "Accept: application/json" -H "Content-type: multipart/form-data" -F "certificate=(a)/Users/matzew/Desktop/encrypted-cert.blah" -F "passphrase=schwarzenegger" -F "production=true" // make sure you have Production certificate and Provisioning Profile -X POST https://SERVER:PORT /CONTEXT/rest/applications/{pushApplicationID}/iOS Where encrypted-cert.blah and "Schwarzenegger" are encrypted data.

Makes sense?

> > > > > > 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(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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev

I will start to file Jiras, but answers inline.

-- abstractj On March 11, 2014 at 3:17:01 AM, Matthias Wessendorf (matzew(a)apache.org) wrote: > > > > Yes if that makes sense to the others like Android variants. And no if we > > just want to use it with iOSVariant, into this case that would apply only > > for iOS applications. > > > > Perfect! > > It does make sense on the 'root' PushApplication. That way other variant > types can benefit from it as well. I think we can(should?) also encrypt the > Google API-Key value. And future variants (other networks) will benefit in > this case as well +1 > > > > > > Currently: > > > > curl -3 -v -b cookies.txt -c cookies.txt > > -i -H "Accept: application/json" -H "Content-type: multipart/form-data" > > -F "certificate=(a)/Users/matzew/Desktop/MyProdCert.p12" > > -F "passphrase=TopSecret" > > -F "production=true" // make sure you have Production certificate and > > Provisioning Profile > > > > -X POST https://SERVER:PORT > > /CONTEXT/rest/applications/{pushApplicationID}/iOS > > > > > > Proposed: > > > > > > curl -3 -v -b cookies.txt -c cookies.txt > > -i -H "Accept: application/json" -H "Content-type: multipart/form-data" > > -F "certificate=(a)/Users/matzew/Desktop/encrypted-cert.blah" > > -F "passphrase=schwarzenegger" > > -F "production=true" // make sure you have Production certificate and > > Provisioning Profile > > > > -X POST https://SERVER:PORT > > /CONTEXT/rest/applications/{pushApplicationID}/iOS > > > > Where encrypted-cert.blah and "Schwarzenegger" are encrypted data. > > > > Ok, so the encrypted data is being uploaded by the user of the UPS, right ? > and hence, no more a direct upload of the plain certificate and the plain > passphrase. > That means there is an extra step for the user, if I see it correct. > > having an extra step for the API to create the (iOS) variant is fine, let's > make sure it's a somewhat simple step for our users, which hopefully than > does not need too much extra steps in the documentation :-) I will think about how to make it less painful to our devs

> > > > > Makes sense? > > > > Yes, I think :-) > Thanks! > > -Matthias > > > > > > > > > > > > > > > > > > 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(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 > > > _______________________________________________ > > > 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 >

> I think it can be completly transparent for the user no (at least in the admin console) ? Retrieving the PK and encrypting can be done "under the hood" while keeping the same UI Flow , no ?