Re: [TLS] Verifying X.509 Certificate Chains out of order

Martin Rex <Martin.Rex@sap.com> Tue, 07 October 2008 11:11 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD783A6B22; Tue, 7 Oct 2008 04:11:03 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F623A6B22 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 04:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.59
X-Spam-Level:
X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+Y8+j5HVspz for <tls@core3.amsl.com>; Tue, 7 Oct 2008 04:11:01 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 19AB53A6864 for <tls@ietf.org>; Tue, 7 Oct 2008 04:11:00 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id m97BA5Bk026150; Tue, 7 Oct 2008 13:10:12 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810071109.m97B9vFl011461@fs4113.wdf.sap.corp>
To: stefans@microsoft.com (Stefan Santesson)
Date: Tue, 7 Oct 2008 13:09:57 +0200 (MEST)
In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3218DDA5593A@EA-EXMSG-C332.europe.corp.microsoft.com> from "Stefan Santesson" at Oct 7, 8 11:04:03 am
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Stefan Santesson wrote:
> 
> Just agreeing on the principle that implementers should be forced to
> send the certificates in order but it definitely must be allowed
> to accept out of order chains.

I have absolutely no problem with implementations that accept an
unordered list.  However, implementations that accept an unordered
list should make sure they find a RELIABLE means to check that
they're always *SENDING* ordered lists, because a simple interop
check with their own client&server code or with other "unordered
accepting" implementations is NOT going to report bugs in
their *sending* implementation.

"Be liberal in what you accept" can be very dangerous with
careless implementors, because it will often make it more difficult
to verify whether your implementation is really conservative
with what it sends.  This may ruin the usefulness of
an originally sensible standard/spec.


>
> As long as I can use, some or all, of the provided certificates
> to construct a valid path, and I'm willing to undertake the effort
> to do so, then it would be quite senseless to force me to reject that path.

I wouldn't be surprised if some implementations of PKI would follow AIA
while building a chain from an incomplete unordered set.
*I* certainly would not want *my* servers to do that.

> 
> Also, In the practical world of cross-certification and bridge CAs,
> it is quite possible that I in any case as relying party only will
> use a subset of the provided certificates.

That's a whole different can of worms.

It should be possible to chop off the overly complexx cross-cert and
bridge-CA nonsense and treat some intermediate CAs as trust anchors
instead.  This is more likely to work and makes failures much
easier to understand.  :)


-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls