Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

Peter Sylvester <> Mon, 14 June 2010 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FA413A6974 for <>; Mon, 14 Jun 2010 11:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qTij8w6u8TxK for <>; Mon, 14 Jun 2010 11:28:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28D353A68CC for <>; Mon, 14 Jun 2010 11:28:23 -0700 (PDT)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x []) by (Postfix) with ESMTP id 62929F0 for <>; Mon, 14 Jun 2010 18:22:26 +0200 (CEST)
Received: from (mintaka.puteaux.on-x []) by varuna.puteaux.on-x (Postfix) with ESMTP id CEC1C17048 for <>; Mon, 14 Jun 2010 18:22:24 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTP id 97B6D77D8 for <>; Mon, 14 Jun 2010 18:22:24 +0200 (CEST)
Message-ID: <>
Date: Mon, 14 Jun 2010 18:22:21 +0200
From: Peter Sylvester <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jun 2010 18:28:24 -0000

> In my TLS code, there is a simple configuration scheme that applications
> use to tell the TLS layer which domain names map to which certificate
> chains.  Once set up, the application doesn't need to do anything more
> since the TLS code then handles certificate selection based on the SNI,
> version, cipher suite, supported signature algorithms, and key usage.
> It's quite complicated.
One might call this a facility intermediate layer to simplify application
coding for "common" cases.
> You might condemn this as some sort of layering violation, but it really
> does make life easier for application writers.  I wrote the code once
> instead of requiring every application writer to have to reinvent it.
Internal API structures and features do not necessarily need to follow
protocol layers and provide for all options. No problem I think.

Whether it is better to have apis aligned with protocol layers depends
on the protocols, the layer structure, application needs, the temperature
of coffee etc.   Shadokism and/or oversimplification may occur.