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

Mike Lin mikelin at MIT.EDU
Sat Mar 2 20:03:24 UTC 2002


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




More information about the Standards mailing list