[TLS] private extension Informational I-D

[<[e-mail]>]

Another idea, prompted by a private message; informational 
RFC anyone? Extension 65535 is formally defined; so lets 
apply it using the conventions of the SSL community when 
(ab)using the 255 or equivalent value in SSL enum types:-

IF a private ciphersuite value is indicated in Server 
Hello:-

(a) TLS extension value 65535 in Client Hello and Server 
Hello may be interpreted as a PRIVATE extension by TLS 
endpoints choosing to support one associated PRIVATE client 
protocols in that private ciphersuite

(b) A Private TLS Extension may have an ExtensionValue that 
should be interpreted as a DER-encoded OID value that MUST 
not be indicated in another Extension of the same 
Client/Server hello message

(c) the private ciphersuite spec shall specify one or more 
private client protocol(s) that is/are associated with one 
or more Private TLS Extensions, including private 
record_type message(s)

NB1 Nothing in the spec of "Extension 
client_hello_extension_list<0..2^16-1>;" prevents one from 
having multiple private extension values, distinguished by 
OID value by convention (b) - which internet-type folks can 
get by abusing the MIB tree, as usual.

NB2 If its necessary to specify the convention that 
record_type (255) is a private record_type, then such an 
Informational RFC can do that too.

We have the equivalent of the modern MIME regime for 
extending MIME, then. WE are only tidying up the conventions 
actually used in the SSL community, by doing this for 65535 
and 255 values. The general practice is supported by TLS 
already, which specified similar conventions (in some areas)

----- Original Message -----
From: <[e-mail]>
To: "Peter Gutmann" <[e-mail]>; "Russ 
Housley" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, January 28, 2007 8:26 AM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

>
> We need a private range for TLS extensions, then. But, 
> this would require IESG review of an update to a standards 
> track document. Lets not bother with that lio.
>
> Or, we introduce immediately introduce an extension with 
> value .next, whose specification says: anyone can use this 
> as a basis for experiment. This Private extension MUST be 
> used with a ciphersuite declared in the private range of 
> ciphersuites.
>
> Nothing prevents a private community declaring private 
> ciphersuite X is identical with RSA_RC4_MD5.
>
>
> ----- Original Message -----
> From: "Russ Housley" <[e-mail]>
> To: "Peter Gutmann" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Saturday, January 27, 2007 11:39 PM
> Subject: Re: [TLS] Please discuss: 
> draft-housley-evidence-extns-00<
>
>> Peter:
>>
>> The TLS IANA rules require a Standards-Track document to 
>> allocate the content type number.
>>
>> Russ
>>
>> At 08:15 PM 1/26/2007, Peter Gutmann wrote:
>>>Nelson B Bolyard <[e-mail]> writes:
>>>
>>> >I still have not heard a convincing case that this 
>>> >stuff belongs in TLS.
>>> >There doesn't seem to be consensus in the WG that it 
>>> >belongs in TLS, either.
>>>
>>>I've already pointed this out before, why not make it an 
>>>Experimental RFC?
>>>That's exactly what they're there for.
>>>
>>>Peter.
>>>
>>>_______________________________________________
>>>TLS mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/tls
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/tls
>> 

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls