[Standards-JIG] The Great Encryption Debate
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,
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
> > 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