IETF Logo Mail Archive

RE: [TLS] extension number conflict

<Pasi.Eronen@nokia.com> Fri, 09 February 2007 10:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTKI-0006yd-LC; Fri, 09 Feb 2007 05:49:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTKG-0006yT-IN for tls@ietf.org; Fri, 09 Feb 2007 05:49:56 -0500
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFTKE-0000CX-3e for tls@ietf.org; Fri, 09 Feb 2007 05:49:56 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l19AkFwr002053; Fri, 9 Feb 2007 12:46:37 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:21 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] extension number conflict
Date: Fri, 09 Feb 2007 12:49:20 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2403C1A6DF@esebe105.NOE.Nokia.com>
In-Reply-To: <45CBB5B5.9020305@pobox.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] extension number conflict
Thread-Index: AcdL2uSDJ/kp8mZIQDSa9g+mKhkR8wAW9Axw
References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com>
From: Pasi.Eronen@nokia.com
To: mike-list@pobox.com, tls@ietf.org
X-OriginalArrivalTime: 09 Feb 2007 10:49:21.0081 (UTC) FILETIME=[F4696A90:01C74C37]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070209124637-07E03BB0-2F1FB4EE/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

mike-list@pobox.com wrote:
> 
> I agree.  I had to disable the code that implements this feature
> since there is no way to access it.  This makes it difficult to
> test, especially between differing implementations.
> 
> For a feature that will obviously be approved, shouldn't there
> be a way to assign it a number sooner than RFC publication?

I think it is *not* obvious that this feature will be exactly 
the same (that is, interoperable with the -02 draft) in the final 
TLS 1.2 RFC. For example, in addition to the hash algorithm, we
might want to signal support for different signature algorithms 
(e.g. there are at least three standardized ways of doing RSA 
signatures, but the current specs sort of assume that everyone
uses only PKCS#1 1.5, ignoring the PSS and ANSI variants).

(But perhaps allocating one extension number for "private use"
might make sense... )

Best regards,
Pasi

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

v2.23.0 | Report a Bug | By Email