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

Martin Rex <Martin.Rex@sap.com> Fri, 10 October 2008 19:29 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 DB1FD3A6858; Fri, 10 Oct 2008 12:29:04 -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 5170F3A68D4 for <tls@core3.amsl.com>; Fri, 10 Oct 2008 12:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.51
X-Spam-Level:
X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=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 kax+CSWT0QDb for <tls@core3.amsl.com>; Fri, 10 Oct 2008 12:29:03 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A6FA43A684F for <tls@ietf.org>; Fri, 10 Oct 2008 12:29:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m9AJTgcN025971; Fri, 10 Oct 2008 21:29:42 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810101929.m9AJTcDf001719@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Fri, 10 Oct 2008 21:29:38 +0200 (MEST)
In-Reply-To: <E1KnBcw-0000hC-1u@wintermute01.cs.auckland.ac.nz> from "Peter Gutmann" at Oct 8, 8 01:25:22 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

Peter Gutmann wrote:
> 
> [Replying to two messages at once]
> 
> Axel.Heider@gi-de.com writes:
> 
> >> I'd say modify it, in fact I'm not sure what the rationale for requiring
> >> ordering was in the original spec, "it's tidier that way" doesn't strike me as
> >> a good argument :-).
> >
> >Consider TLS on low-end or embeddede devices with limited ressources. Walking
> >through the chain becomes difficult or even impossible if there is no order.
> 
> Again, how can you create an implementation that can run the entire SSL
> protocol but can't manage a few 32-bit pointers across three or four certs?
> This seems like a total red herring, it's difficult to think of an
> implementation that can perform the necessary cert verification but somehow
> can't manage an extra pointer swap.

It all depends on the PKI software (and the modularization of APIs
and datatypes of that PKI software) how much wasted effort there is.

Since Stefan mentioned it lets take a look at Microsoft SChannel/CryptoAPI
how it might be working there.

I don't know the detail, but Stefan mentioned that "CertGetCertificateChain"
is called used at some point.

Looking at the (relevant) input and output parameters:
  CertGetCertificateChain
       PCCERT_CONTEXT        pCertContext,
       HCERTSTORE            hAdditionalStore,
       PCCERT_CHAIN_CONTEXT* ppChainContext

So in order to pass any additional certs besides the initial
end entity cert from the certificate_list of the SSL/TLS handshake
message, one must first create a "HCERTSTORE" and parse&store
the additional certificates from the certificate_list there.

The output of CertGetCertificateChain() is a CERT_CHAIN_CONTEXT
that contains one (or more) CERT_SIMPLE_CHAIN.  I don't see it in
the documentation (and its not obvious from the function name),
but I assume that the signatures on the output certificate chain has
also been verified.


Lacking experience I don't know how many duplicates of unparsed
certificates are being created in this process.

An optimized approach with a differently modeled PKI Software would
have built a CERT_SIMPLE_CHAIN kind of structure straight from the
SSL/TLS handshake exactly as it falls out of the ASN.1 parser
and use and then called a certificate chain verifier that
looks for a trust anchor matching this chain and checks the
relevant certificate attributes and signatures on the path
from the chosen trust anchor down to the end entity cert.

It may be less generic, but certainly it will be more efficient
in terms of CPU cycles.


While it might not need a lot of pointer-swapping to reorder
certificates in the chain, it will require a significant amount
of non-trivial comparisons to determine what the correct order is.


I haven't benchmarked the MS-CryptoAPI approach, but I assume that
the vast number of features that are offered come at a cost.
 

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