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

mrex@sap.com (Martin Rex) Wed, 13 May 2015 00:16 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 DE2381A8710 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 17:16:40 -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 ir8xxXdTIAJh for <tls@ietfa.amsl.com>; Tue, 12 May 2015 17:16:39 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C7E1A870B for <tls@ietf.org>; Tue, 12 May 2015 17:16:38 -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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 6F55B2AB81; Wed, 13 May 2015 02:16:36 +0200 (CEST)
X-purgate-ID: 152705::1431476196-0000413A-86932C39/0/0
X-purgate-size: 1492
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 48A60414BE; Wed, 13 May 2015 02:16:36 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3C5141B2EB; Wed, 13 May 2015 02:16:36 +0200 (CEST)
In-Reply-To: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com>
To: ryan-ietftls@sleevi.com
Date: Wed, 13 May 2015 02:16:36 +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: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HELEero5GqGg5UVBtTnOWntnqYI>
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: Wed, 13 May 2015 00:16:41 -0000

Ryan Sleevi wrote:
> 
> Your example (access.redhat.com) is one that we had to work around on OS X
> due to quirks of the client not supporting trust anchors (e.g.
> https://code.google.com/p/chromium/issues/detail?id=236112 ).
> 
> That is, if you supply your (b) or (c), for example, you'll break any
> application using Security.framework for certificate verification
> (including all those that use CFURL & friends). It seems that Safari has
> special logic not present in the OS to work around that issue.

When looking at the above bug report, I agree with the particular
statement of rsleevi@chromium.org's bug report:

  This allows the 'proper' chain to be built (eg: through AIA fetching).
  However, such behaviour is not desirable for both performance reasons
  and because it may mask real configuration errors (eg: Issue 122500 ) 

Has adding the crossCA variant of the new Baltimore rootCA cert ever
been considered/tried?  I mean dropping the old 1024-bit rootCA should
become irrelevant when the the 2048-bit crossCA variant is added
as trust anchor.  There is no practical difference between the
self-signed variant and the crossCA variant of that trust-anchor.
And if the PKIX implemenation is a little dense and does not recognize
the equivalence all by itself, then configuring both variants as
trust anchors should do the necessary magic.

Did the supplier of the relevant PKIX implementation fix this implementation
shortcoming?

-Martin