[standards-jig] [jepnews] JEP-0020: Client Feature Negotiation

Thomas Muldowney temas at box5.net
Sun Mar 3 05:06:04 UTC 2002

I guess that's a big thing for me.  If we could get off of this being a
potential key exchange mechanism and rather a simple suggested syntax it
might be a bit more clear in our heads (Especially since I already
thought of a kind of fun man in the middle attack based on a weak key
negotiation system).  

It almost seems to me that this would be something JEP authors could
take and have a section saying, "Here are our options used with our
system, and here's what they mean so developers can show them to end
users if they deem necessary".  I'm also wondering if there is ever a
case where you would need to do multiple exchanges?  To take that a step
further, would you ever need to know the previously selected data?  I
seem to think it would be fine to just know what you previously selected
on the receiving side, but I just wanted to put it out there to make
sure I'm not missing anything.


On Sat, 2002-03-02 at 14:03, Mike Lin wrote:
> I agree that it will probably be useful to define at least a rough
> top-level namespace that can be used for feature negotiation. But I
> don't think it is realistic that we will define this one namespace that
> will be satisfactory for all (or even most) negotiation requirements.
> I even question whether JEP-0020 in its present form is adequate for
> building a cryptosystem, which is its stated initial purpose. For
> example, say one uses it to determine that both interested parties
> support AES. Now you also have to agree on: 1) key exchange algorithm;
> 2) actual public key exchange; 3) symmetric key length; 3) cipher block
> mode; 4) cryptographic encoding (PKCS/OpenPGP/X.509); 5) wire encoding
> (base64) 6) initialization vector; and so on. Do you do this in a dozen
> sepearate negotiations? Or do you maybe break it down so that you agree
> on rsa-openpgp-radix64 and aes-cbc-128 options, then perform key/IV
> exchange? This has to be worked out between developers, and it's clearly
> not something that can be extended to be useful for applications beyond
> cryptosystems.
> So it seems to me that in the end what you will end up doing for setting
> up negotiation for various different extensions is defining many,
> specialized protocols with their own unique semantics that happen to
> sort of look syntactically the same. It doesn't really matter that they
> look the same, though, because you already had to do so much
> developer-negotiation to agree on which <option>s to define and what
> they mean that you've basically created your own protocol anyway.
> I think this is another really interesting problem, and I think JEP-0020
> is useful to at least have a starting point for those
> developer-negotiations. Pending a few details (like who makes up the
> <option>s), I'd vote it in. I just hope we're not too over-optimistic
> about the kinds of problems it will solve.
> -Mike
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020302/f9a5bbfd/attachment.sig>

More information about the Standards mailing list