<p>[mobile not ideal, so bear with me]</p>
<p>The general idea is the sender generates the content keying material, encrypts the stanza, and sends. The recipients then ask the sender for the keying material, providing their public key for the sender to use for protecting it specifically for a given recipient.</p>

<p>This will probably work for your scenario, assuming the publisher Anne subscribers are ”always” online.<br></p>
<p>- m&m<br>
(mobile; terse)</p>
<div class="gmail_quote">On Nov 13, 2012 7:59 PM, "mat henshall" <<a href="mailto:mat@squareconnect.com">mat@squareconnect.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matthew,<div><br></div><div>To give you an understanding of our application, we have small embedded devices that use PEP to publish changes to their state (for example, a light is turned on, a temperature sensor sends a measurement, a lock is unlocked). Anyone on it's roster who has indicated interest in that event type gets the event using the server's PEP implementation. </div>

<div><br></div><div>I dont think I fully understand how the keys work. In PEP, the recipient of the message is the account of the sender. The PEP service takes care of forwarding it to each interested resource. How do we have a single encrypted message that can be decrypted by multiple users? I think it is late at night and my head is exploding with SMK's and CMK's. </div>

<div><br></div><div>Mat</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 8:35 PM, Matthew Miller <span dir="ltr"><<a href="mailto:linuxwolf@outer-planes.net" target="_blank">linuxwolf@outer-planes.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>It might still be possible to use PEP or pubsub, but it does require the publisher and subscribers to be available at the same time.</p>


<p>I've be happy to adjust text to make it at least allowed.</p>
<p>I should note that this draft is still in flux because of work ongoing in the JOSE WG at the IETF.<span><font color="#888888"><br></font></span></p><span><font color="#888888">
<p>- m&m</p></font></span><div><div>
<div class="gmail_quote">On Nov 13, 2012 7:23 PM, "mat henshall" <<a href="mailto:mat@squareconnect.com" target="_blank">mat@squareconnect.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Thanks Peter,<div><br></div><div>I had missed the later draft-miller-xmpp-e2e somehow in my poking at links.</div><div><br></div><div>One question is how do you accomplish encryption of messages that are published through PEP or Pub-Sub? Seems that the draft-miller specifically prohibits that (section 8)?</div>



<div><br></div><div>Mat</div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 7:37 PM, Peter Saint-Andre <span dir="ltr"><<a href="mailto:stpeter@stpeter.im" target="_blank">stpeter@stpeter.im</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><br>
On 11/13/12 4:49 PM, mat henshall wrote:<br>
> We have an application that needs to be able to encrypt and sign<br>
> messages and IQ stanza's that contain custom elements 'end to end'<br>
> from one client to another, possibly across multiple federated<br>
> services.<br>
><br>
> Looking at RFC 3923, ther seems to be very little practical<br>
> application of this specification.<br>
><br>
> Is there any reason?<br>
><br>
> Should I ignore this? If so what would the community suggest?<br>
<br>
</div>We've tried 5+ times to build end-to-end encryption. We've failed each<br>
time.<br>
<br>
1. PGP (XEP-0027) - never widely adopted, who has PGP keys?<br>
<br>
2. SMIME+CPIM (RFC 3923) - checking off a security box for the IETF<br>
<br>
3. xmlenc (never documented) - might be used somewhere, but those<br>
people aren't talking<br>
<br>
4. ESessions (XEP-0116) - implemented once, no other adoption<br>
<br>
5. XTLS (draft-meyer-xmpp-e2e-encryption) - experimental, didn't move<br>
forward<br>
<br>
At this point I think there are other solutions under discussion:<br>
<br>
6. OTR - <a href="http://www.cypherpunks.ca/otr/" target="_blank">http://www.cypherpunks.ca/otr/</a><br>
<br>
7. XMPP e2e - draft-miller-xmpp-e2e<br>
<br>
I sure hope we'll settle on one of those before the heat death of the<br>
universe. Your feedback is welcome. :)<br>
<br>
Peter<br>
<br>
- --<br>
Peter Saint-Andre<br>
<a href="https://stpeter.im/" target="_blank">https://stpeter.im/</a><br>
<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)<br>
Comment: Using GnuPG with Mozilla - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEYEARECAAYFAlCi9cEACgkQNL8k5A2w/vy+ygCfYVRu0YZBMdwyDP30h1keLurc<br>
5wwAoItpAnu7E4OiLZraazOpWwnKx+dV<br>
=PkuA<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
JDev mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a><br>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org" target="_blank">JDev-unsubscribe@jabber.org</a><br>
_______________________________________________<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Mat Henshall<br>Founder and CEO, Square Connect, Inc.<br>San Jose, CA<br><a href="http://www.squareconnect.com" target="_blank">www.squareconnect.com</a><br>



cell: <a href="tel:650.814.7585" value="+16508147585" target="_blank">650.814.7585</a><br>
</div>
<br>_______________________________________________<br>
JDev mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a><br>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org" target="_blank">JDev-unsubscribe@jabber.org</a><br>
_______________________________________________<br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
JDev mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a><br>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org" target="_blank">JDev-unsubscribe@jabber.org</a><br>
_______________________________________________<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Mat Henshall<br>Founder and CEO, Square Connect, Inc.<br>San Jose, CA<br><a href="http://www.squareconnect.com" target="_blank">www.squareconnect.com</a><br>

cell: <a href="tel:650.814.7585" value="+16508147585" target="_blank">650.814.7585</a><br>
</div>
<br>_______________________________________________<br>
JDev mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/mailman/listinfo/jdev</a><br>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org">JDev-unsubscribe@jabber.org</a><br>
_______________________________________________<br>
<br></blockquote></div>