[Standards-JIG] The Great Encryption Debate

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Mon Aug 15 20:11:47 UTC 2005

On Friday 12 August 2005 09:21 am, Ian Paterson wrote:
> JEP-0116 includes all the necessary lower-level specifications that are
> hidden away from readers of JEP-0027 and RFC 3923 (in the PGP and S/MIME
> documents). If, for a second, we imagine implementations of PGP and
> S/MIME do not exist then, IMHO, JEP-0116 is far easier to implement than
> either of the roughly equivalent combinations of JEP-0027 and PGP, or
> RFC 3923 and S/MIME.

Certainly, but I'm not sure if this helps your point.  All over computing, we 
stand on each others' shoulders.  There needs to be a strong reason to scrap 
existing code and protocols, especially when it comes to security.  IMO, 
easing e2e implementation in Javascript is not one of them.  You may have to 
write less code now, but the majority of us will have to write a lot more 
(certainly more than you are saving).

> Of course I would like JEP-0116 to be as simple as possible. Perhaps we
> should also write a synopsis JEP (at the level of JEP-0027 for
> developers using a library), and even (eventually) move "Offline
> Esessions" into another JEP?

A synopsis JEP would be useless at this point.  Without libraries or 
standards, there can't be anything like JEP-27 (which is essentially another 
"How to use Foo technology with Jabber").  You'd need to make the Foo 
standard first.

> > object encryption is simpler to program,
> > and simpler to deploy, particularly for signing
> > I additionally plan to implement RFC 3923
> > However, I also find it annoying having two
> > ways to do the same thing.
> I'd *really* like to avoid the need for that too.
> I made a few minor changes to the JEP. Now, if you've implemented
> JEP-0116, then one-to-one object encryption and object signing are
> trivial. See the notes about <terminate/> in Sections 6.1.5 and 6.2.4 of
> version 0.6: http://www.clientside.co.uk/jeps/jep-0116/jep-0116.html

Nice try, but I think this kind of defeats the point.  Simple object 
encryption is intended to be simple.  Session encryption is intended to be 
more capable.  Your proposal here is both complex and less capable.

> > [what about] broadcast signed news items[?]
> Two possible answers:
> Short:  One-to-many is out of scope for JEP-0116.
> Long:  Yes. It is inefficient to calculate a different signature (and DH
> key) for every user.

Two possible responses:

Short: Yuck. :)

Long: While this would work for directed stanzas (despite being inefficient), 
signed stanzas would also be useful in cases where directed stanzas are not 
easily possible, such as pubsub and groupchat.

> We seem to have a consensus (including Peter) that:
> "It is not possible or desirable to obtain consensus on a single method
> of verifying that a public key (RSA or DSA) is associated with a JID".
> In the interests of coming to another consensus, here is another
> question: Does that consensus mean we can rule out both RFC 3923
> (S/MIME) and JEP-0027 (PGP) since they are tied to the X.509 (CA) and
> PGP (WoT) methods respectively?

Sort of.  Obviously JEP-27 has got to go, mainly because it isn't modern.  
Extending RFC 3923 to support PGP or other stuff would be one answer.


More information about the Standards mailing list