On Mon, Mar 10, 2014 at 11:38 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
Ahoy, answers inline.

--
abstractj

On March 10, 2014 at 6:01:33 PM, Matthias Wessendorf (matzew@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.

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

 

>
>
> > 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.

perfect!
 

Currently:

curl -3 -v -b cookies.txt -c cookies.txt
  -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
  -F "certificate=@/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=@/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 :-)

 
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@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




--
Matthias Wessendorf

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