Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13

[<home_pw@xxxxxxx>]

well done!

----- Original Message -----
but I'd like to see the private range retained.  I am actually
> planning to use some private ciphersuites soon in an experiment.
>
> Mike


(a) there is good basis now to define a class of "local" changeciphersuite 
values,
to allow signaling of per-ciphersuite customizations of the finished/final
process. I already gave the example of completing SSLv3 fortezza_dms
generation of sessionTEKs with the UKM processes for deriving key for
SSL connections, that could then control active state duplication (on the 
current,
multiplexed, or different TLS transport) and  session resumption (on a new
transport instance)

(b) we see GSSAPI-proposal basically introducing a mechanism-negotiation 
sub-protocol,
qualifying the negotiation of some nominal GSS ciphersuites essentially, for
PRF mechanisms and who knows what else, tomorrow. This same process could 
easily
now mandate the changeciphersuite value to be used, and thus key 
derivation(s) used
to create connection states, for each of the the 4 channels per SSL 
Connection
instance

(c) we see local ciphersuites being used, possibly to profile mainstream
ciphersuites (E.g facilitate SGC variant for std RSA ciphersuites). That is, 
do
IETF RSA, but don't do or perhaps add rule X on a renegotiation (e.g. use 
cache of
public keys  for server auth) when the capability negotiation from the 
GSSAPI negotiation
signals that a particular class of renegotiation is required, using "local
ciphersuite" local.X ...whose local-number and semantics is associated with 
some
GSSAPI mechanism oid (an unlimited size name space). 


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls