Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 866

[tlyu - Thu Apr 17 19:51:38 2003]:
> Changing the default subkey negotiation doesn't break the
> AP-REQ/AP-REP exchange, since those messages only contain ciphertext
> encrypted using the ticket session key.  They may break the state of
> what applications are expecting in terms of local and remote subkeys,
> though.

Right.  I think the existing behaviour has to remain the default.

> To achieve "server subkey wins", we sould have to stomp on
> local_subkey in the client and on remote_subkey in the server.  This
> might cause pointer aliasing nastiness, but is very probably
> manageable, given that the structure involved is supposed to be
> opaque.

Er, why can't server subkey wins (or any other variation) be a
per-auth-context
option that can be set by the application, with the current
ignore-the-server's-
offered-subkey behaviour as the default?

Nico