<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 12:11 AM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Matthias Wessendorf wrote:<br>
&gt; Another idea....<br>
<br>
I can see a lot of good ideas here, but we have to start to file jiras.<br></blockquote><div><br></div><div style>Right, but I wanted to &quot;validate&quot; these ideas, instead of creating countless JIRAs, all being closed &quot;won&#39;t fix&quot; / &quot;does not make sense&quot;. Main intention here is really to ask for help, in validating these thoughts</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There will be several several ways to make a system secure.<br>
<br>
IMO start simple, make it ultra secure later.<br></blockquote><div><br></div><div style>yeah, that&#39;s my take on it too</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
&gt;<br>
&gt; We generate, for EACH variant, an &quot;access-key&quot; with a generated<br>
&gt; secret(password).<br>
<br>
</div>What do you mean about secret? A shared secret? Now we have another<br>
problem, you must encrypt this shared secret.<br></blockquote><div><br></div><div style>secret == password</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
This accessKey:secret combination would be, similar to<br>
&gt; the previous email, ONLY be able to perform updates for &quot;device<br>
&gt; (un)registration&quot;.<br>
&gt;<br>
&gt; It would be NOT possible to use this combination for sending messages to<br>
&gt; a device, (read: our HTTP send interface would not allow this<br>
&gt; accessKey:secret combination).<br>
&gt;<br>
&gt;<br>
&gt; Not, sure, but this is (I guess) a bit simpler, initially, instead of<br>
&gt; using private/public key approach.<br>
&gt;<br>
<br>
</div>I&#39;m still confuse, about what do you want to encrypt and why. Why not<br>
only create APP-KEY as a point of start, then we figure out how to<br>
authorize or not a server.<br></blockquote><div><br></div><div style>Not sure I understand what you mean, but I am not talking about &quot;authorize an server&quot; (e.g. for sending mails to devices). </div><div style>These mails are around: devices registers its &quot;application installation&quot; by submitting &quot;token&quot; to a mobile Variant, (&quot;I am an instance of you,&quot;)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then several people, including me suggesting it will say &quot;it&#39;s not<br>
safe&quot;. Then you reply with &quot;fix it&quot; and we can make it work.<br></blockquote><div><br></div><div><br></div><div style>Not sure what that means? Why would *I* just reply &quot;fix it&quot;? Again, this was intended for discussion, not &quot;do this, do that&quot;.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a><br>
</div><div class="HOEnZb"><div class="h5">&gt; &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     Hi,<br>
&gt;<br>
&gt;     once the app is installed on the phone (or launched in a browser),<br>
&gt;     we (as discussed in the spec/mailing list) need to upload the<br>
&gt;     &quot;device token&quot; (or channelID) from the actual device/channel to the<br>
&gt;     Unified Push Server.<br>
&gt;<br>
&gt;<br>
&gt;     My questions:<br>
&gt;     Is it safe, if every &quot;Mobile Variant&quot; has a Private/Public Key ???<br>
&gt;<br>
&gt;     The UP server keeps the private one.<br>
&gt;     Once we register a new mobile variant (e.g. HR for Android, HR for<br>
&gt;     iPad, HR for iPhone, ...) EACH variant has ONE Private/Public key<br>
&gt;<br>
&gt;<br>
&gt;     The Public Key of this combo would be &quot;coded&quot; into the actual mobiel<br>
&gt;     application...<br>
&gt;<br>
&gt;     On EVERY iOS app, it would use the PubKey from the iOS Variant, on<br>
&gt;     EVERY JS-app, it would use the PubKey from the SimplePush Variant, etc<br>
&gt;<br>
&gt;<br>
&gt;     So, that means EVERY installation (on the devices) would have that<br>
&gt;     pbulci key...<br>
&gt;<br>
&gt;     Would that be (extremely) odd, if &quot;1 Mio Russian hacker&quot; would have<br>
&gt;     that public key, used on the device, to perform some sort of &quot;auth&quot;<br>
&gt;     (e.g. via HTTP BASIC (just saying.....)) against the server, in<br>
&gt;     order to upload the &quot;device token&quot; ??<br>
&gt;<br>
&gt;<br>
&gt;     Note: This Private/Public key would/should be EXCLUSIVE for &quot;device<br>
&gt;     registration&quot;. And really ONLY.. :-)<br>
&gt;<br>
&gt;     So that this &quot;Private/Public key&quot; pair can NOT be used (==invalid)<br>
&gt;     for sending messages to the installations, or creating the<br>
&gt;     Push-Applications / Mobile Variant Constructs.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     Greetings,<br>
&gt;     Matthias<br>
&gt;<br>
&gt;     --<br>
&gt;     Matthias Wessendorf<br>
&gt;<br>
&gt;     blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;     sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;     twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Matthias Wessendorf<br>
&gt;<br>
&gt; blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><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>
</div></div></blockquote></div><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>
</div></div>