IETF Logo Mail Archive

Re: [TLS] RFC 5878 - why?

Marsh Ray <maray@microsoft.com> Tue, 17 September 2013 07:31 UTC

Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766611E8391 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 00:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8lyYukors6V for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 00:31:00 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id AD75F11E8390 for <tls@ietf.org>; Tue, 17 Sep 2013 00:31:00 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB165.namprd03.prod.outlook.com (10.255.212.139) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 07:30:58 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Tue, 17 Sep 2013 07:30:58 +0000
From: Marsh Ray <maray@microsoft.com>
To: Trevor Perrin <trevp@trevp.net>
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCwgAAHfQCAAAKG8A==
Date: Tue, 17 Sep 2013 07:30:57 +0000
Message-ID: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
References: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com> <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com> <CAGZ8ZG3R2-Egermz5Vefu18mD2KAvXOXcG++HJut_rLKapeH4Q@mail.gmail.com>
In-Reply-To: <CAGZ8ZG3R2-Egermz5Vefu18mD2KAvXOXcG++HJut_rLKapeH4Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(51704005)(81542001)(53806001)(46102001)(51856001)(33646001)(83072001)(56776001)(65816001)(74706001)(54356001)(80022001)(81686001)(81816001)(83322001)(19580405001)(19580395003)(80976001)(47976001)(47736001)(50986001)(49866001)(4396001)(54316002)(76482001)(63696002)(74876001)(59766001)(79102001)(77982001)(31966008)(74662001)(74502001)(47446002)(81342001)(76786001)(74316001)(76796001)(76576001)(77096001)(69226001)(74366001)(56816003)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB165; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 07:31:06 -0000

> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Tuesday, September 17, 2013 12:12 AM
> Subject: Re: [TLS] RFC 5878 - why?
>
> But those specific types (or any others) could just have been defined as TLS
> Extensions.
> Also, note 5878 only has an 8-bit space for "authZ types", which seems
> *much worse* than just using 16-bit TLS extension numbers in terms of
> number exhaustion or risk of collision.

The WG must have felt that it was worth establishing a separate IANA registry for this specific purpose rather than piling them into the extension registry. An entire protocol could be defined in terms of exchanging sets of (ID, optional scalar value) pairs, but TLS tends to like structures that are nested a little deeper according to their semantics.

I agree, a single octet seems stingy. But if it runs out the code space can be extended with only minor ugly.

> (Does anyone actually use SAML in TLS??  or X.509 Authorization certs?).

Well, it'd be a lot harder without an interoperable spec for it! :-)

- Marsh

v2.2.0 | Report a Bug | By Email