...primarily because there's no "record_type extension" mechanism. There's not even a defined range for experimental ones. Yes, it's security-critical. And yes, new record types cannot be created without WG action. However, I should think that this would be a VERY good reason for defining a range of record types that can be experimented with, and which can be guaranteed to be safely ignored by non-experimental stacks. and if I had any idea how to write an RFC or who to submit it to, I'd write up an idea for how to handle it. -Kyle H On 12/21/06, Peter Williams <home_pw@xxxxxxx> wrote:
Ive never fathomed why folks dont just invent their own client protocols of the Record Protocol for user auth purposes, give it a record_type, and mandate the dispatcher performs the custom SSL handshake extension directly upon session state change after the finish protocol, discarding any APDU till it completes, and sets its own secure state, a new modified Connection secure sub-state peculiar to the enhancement.. This is what the record_type extension capability was for! If I were doing GSSAPI 1-token userauth (a signed blob, of the current write mac?), I'd do it there, also.
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls