Re: [TLS] HTTPS client-certificate-authentication in browsers

Martin Rex <mrex@sap.com> Tue, 26 July 2011 20:52 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693B21F8A55 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 13:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.858
X-Spam-Level:
X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNQ0+spt-KAe for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 13:52:02 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE43821F8A4D for <tls@ietf.org>; Tue, 26 Jul 2011 13:52:01 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6QKq0TP003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 22:52:00 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com (Anders Rundgren)
Date: Tue, 26 Jul 2011 22:51:59 +0200 (MEST)
In-Reply-To: <4E2F1B65.2080404@telia.com> from "Anders Rundgren" at Jul 26, 11 09:54:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jul 2011 20:52:02 -0000

Anders Rundgren wrote:
> 
> You have a rather elitist way of discussing things.
> 
> It actually quite hard writing an HTTPS CCA based web app that
> has similar login and session characteristics as one using password
> authentication.

But that is a clear abuse of the TLS client certificate technology
and _not_ supposed to be usable in this fashion.
 

> 
> In your opinion this is an advantage; in my world it represents a
> hurdle for adoption.

If you are _not_ looking for seamless single Sign-On, then
TLS client certs are not the right tool for what you want to
accomplish (square peg, round hole).


> 
> Anyway, banks are investing huge in app-level PKI authentication
> so there is apparently a huge ignorant crow out there.

But if the "frontend" they are using something as security-broken
as a plain web browser, then the technology they would need
is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data
over well-definied application protocol units.


>
> The there are some really interesting differences in path building
> (which of course is NOT specified at all by TLS) that for example
> have forced people importing immediate CAs to PC before being able
> to login using a smart card.

What particular problem are you facing?


The TLS protocol is _very_ clear that a Certificate message must
contain a FULL path, omitting _at_most_ the self-signed certificate
at the end.  There are several TLS implementations out there with
significant brokeness with respect to the Certificate handshke
message (e.g. OpenSSL) which will omit more than just the
self-signed certificate at the end of the certification path,
send certificates out-of-order and even include arbitrary
non-path certificates.  Things that could be trivially checked
and reported as configuration errors on the server side upfront,
instead of dumping garbage on communication peers in clear
violation of the specification.


-Martin