Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Chris Newman <chris.newman@oracle.com> Fri, 19 August 2011 18:16 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JIGqjJ034976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2011 11:16:52 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p7JIGqtv034975; Fri, 19 Aug 2011 11:16:52 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JIGpiY034970 for <ietf-pop3ext@imc.org>; Fri, 19 Aug 2011 11:16:51 -0700 (MST) (envelope-from chris.newman@oracle.com)
Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7JIHH8X024660; Fri, 19 Aug 2011 18:17:18 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7JIHBb6058993; Fri, 19 Aug 2011 18:17:12 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from [10.159.44.76] (dhcp-rmdc-twvpn-2-vpnpool-10-159-53-10.vpn.oracle.com [10.159.53.10]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ60062HTGL1W00@gotmail.us.oracle.com>; Fri, 19 Aug 2011 11:17:11 -0700 (PDT)
Date: Fri, 19 Aug 2011 11:17:09 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Mykyta Yevstifeyev <evnikita2@gmail.com>, ietf-pop3ext@imc.org
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Message-id: <7BEC116FEB251DB1F9B7B5CF@96B2F16665FF96BAE59E9B90>
In-reply-to: <4E4E472A.8030709@isode.com>
References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E4E472A.8030709@isode.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

--On August 19, 2011 12:21:14 +0100 Alexey Melnikov 
<alexey.melnikov@isode.com> wrote:
> Hi Chris,
> My personal replies are (without consulting with Mykyta):
>
> Chris Newman wrote:
>
>>> From a technical viewpoint, I have two suggestions:
>>
>> Add to section 2.1:
>>
>>  Servers that lack configuration to accept an X.509 client certificate 
for
>>  authentication purposes MUST NOT send a CertificateRequest handshake to 
the client
>>  during TLS negotiation.
>
> I am wondering whether this is actually possible to enforce using
> existing TLS stacks. I would rather not make this a MUST NOT level
> requirement if there are no APIs for this in, for example, OpenSSL.

I'd be fine with a SHOULD NOT.

It's an important usability issue -- many clients pop up an intrusive 
"certificate selection dialog" if the server asks for a certificate. The 
NSS APIs support this check although the APIs to do so are difficult to use 
and non-obvious (you have to search for a cert with a client-certificate CA 
trust flag in the certificate db).

		- Chris