Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS

"Kemp, David P." <DPKemp@missi.ncsc.mil> Mon, 19 December 2011 16:29 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF121F8B47 for <pkix@ietfa.amsl.com>; Mon, 19 Dec 2011 08:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 eVKpIzzPbL+l for <pkix@ietfa.amsl.com>; Mon, 19 Dec 2011 08:29:31 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id E369221F8B13 for <pkix@ietf.org>; Mon, 19 Dec 2011 08:29:30 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id pBJGTSZi089492 for <pkix@ietf.org>; Mon, 19 Dec 2011 11:29:30 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 11:30:18 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 19 Dec 2011 11:29:28 -0500
Message-ID: <C1A47F1540DF3246A8D30C853C05D0DA01B96B87@DABECK.missi.ncsc.mil>
In-Reply-To: <p06240807cb15095d39e4@[192.168.144.140]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS
Thread-Index: Acy+ZpeAu5DBXW5fTmyGu0qU8cWvGgAAhh1g
References: <201112151802.pBFI2xie023478@fs4113.wdf.sap.corp><201112190951.03196.rob.stradling@comodo.com><p06240805cb14fc44280d@[192.168.144.140]><201112191510.15109.rob.stradling@comodo.com> <p06240807cb15095d39e4@[192.168.144.140]>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: pkix@ietf.org
X-OriginalArrivalTime: 19 Dec 2011 16:30:18.0703 (UTC) FILETIME=[7EEB4DF0:01CCBE6B]
Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2011 16:29:31 -0000

-----Original Message-----
From: Stephen Kent
> From: Rob Stradling
>> Relaxing the decoding rules certainly doesn't alleviate the problem, 
>> but IMHO it doesn't necessarily make the problem any worse.  For 
>> example, if we'd decided instead to persist with only allowing 
>> correctly encoded CSRs, customers with broken CSR generation software

>> would've simply gone to a different CA that did accept their 
>> incorrectly encoded CSRs.  There would still be no incentive for the 
>> authors of the broken software to fix their code.
>
> The ability to go to a second CA that does not require correct
> syntax arises precisely because such CA behavior is not
> perceived as "bad." 

Accept/Reject is a false dichotomy.  Why is Flag not among the
alternatives:

"Warning: the certificate signing request submitted by browser <UA
string> is garbled.  We've done our best to interpret your request, but
please check to ensure that the certificate is acceptable before putting
it to use."

That ought to shame any vendor capable of feeling shame :-).

Dave