Re: [TLS] Update spec to match current practices for certificate chain order

mrex@sap.com (Martin Rex) Tue, 12 May 2015 19:14 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94F91A7034 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWbuX05ro1mX for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:14:48 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB98F1A1AA6 for <tls@ietf.org>; Tue, 12 May 2015 12:14:47 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EDCA744450; Tue, 12 May 2015 21:14:45 +0200 (CEST)
X-purgate-ID: 152705::1431458086-00005316-8092B018/0/0
X-purgate-size: 1639
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9D27541376; Tue, 12 May 2015 21:14:45 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8FB0A1B2EB; Tue, 12 May 2015 21:14:45 +0200 (CEST)
In-Reply-To: <17a92a9a6272ba2735dd0553fb527c3a.squirrel@webmail.dreamhost.com>
To: ryan-ietftls@sleevi.com
Date: Tue, 12 May 2015 21:14:45 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150512191445.8FB0A1B2EB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/EwYoVGmLh6Am5OqLqu725Fvj0CM>
Cc: tls@ietf.org
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 12 May 2015 19:14:49 -0000

Ryan Sleevi wrote:
> On Tue, May 12, 2015 12:04 pm, Martin Rex wrote:
>>  The *CORRECT* approach would be to issue a cross-CA certificate
>>  for (5) Root 2 signed by (4) Root 1, lets call it (5b), and
>>  the correct path to send for servers would be
>>
>>  (1)+(2)+(3b)+(5b)+(4)
>>
>>  that would be fully conforming with the existing requirements,
>>  fully comprehensible for clients that feed the certificate_list
>>  from the Certificate handshake message into "Basic Path Validation".
> 
> How did I know you would suggest this?
> 
> Ah, because I addressed it in the original email, when I said
> 
> "As much as you might wish to yell that they shouldn't have done (3a)/(3b)
> like that, and instead (5) should have been certified by (4), there are a
> large number of reasons why that doesn't happen, and the above is actually
> quite common (I know of at least three different organizations who will
> have to go through the above flow right now to avoid issues)"

there is no "shouldn't have done (3a)/(3b)".  They can simple create
that crossCA cert *NOW* and start distributing it, and things will
work just fine.

The problem with your original proposal is, that no *CORRECT* TLS
implementation will allow you to send such junk in a TLS Certificate
handshake message, so this will simply not be an option.

Right now, we still have a stick to make that CA create such a crossCA
cert.

But you're not only asking to make client tolerate junk, you seem to
be asking to actively break correct TLS implementations to start sending
junk and create new interoperability problems.


-Martin