Re: [TLS] TLS-OBC proposal

Martin Rex <mrex@sap.com> Tue, 06 September 2011 20:03 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 5661221F8E2F for <tls@ietfa.amsl.com>; Tue, 6 Sep 2011 13:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Level:
X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQqirSVwaRJ1 for <tls@ietfa.amsl.com>; Tue, 6 Sep 2011 13:03:19 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB88121F8E06 for <tls@ietf.org>; Tue, 6 Sep 2011 13:03:14 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p86K4xs9028281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 22:04:59 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109062004.p86K4wM9020670@fs4113.wdf.sap.corp>
To: chris@randomnonce.org (Chris Richardson)
Date: Tue, 6 Sep 2011 22:04:58 +0200 (MEST)
In-Reply-To: <CADKevbDYnjzFe8w7MTyQWhBUBRLo_vUROEy2uinjaA3cwpqq9w@mail.gmail.com> from "Chris Richardson" at Aug 23, 11 07:25:26 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] TLS-OBC proposal
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, 06 Sep 2011 20:03:20 -0000

Chris Richardson wrote:
> 
> Should that be a MUST, or at least a SHOULD?  If OBC has been
> negotiated, why would a CA-signed cert be used?

The original design behind TLS client certs is exactly the idea of per-server
client certs.

Each Service operator would run a CA and issue certificates
to clients, and the TLS client would be able to automatically select
an appropriate client cert based on CA listed in the
certification_authorities list sent by the TLS server.

Btw. in SSLv3 and TLSv1.0 the protocol does _NOT_ allow to send
a Certificate Request handshake message with an empty
certification_authorities element, although there are numerous
defective SSL&TLS server implementations out there that ignore
that protocol requirement, so TLS clients usually do not break
on such broken server behaviour.   Our TLS client will unconditionally
send back an "SSL no certificate alert" (for SSLv3) or and empty
Certificate handshake message (TLSv1.0) when receiving an
invalid CertificateRequest handshake message with an empty
certificate_authorities list.


Some extremely broken TLS server implementations (I've heard complaints
about a big network components vendor) even go as far as completely
lacking a possibility to configure CA certificates for the
certificate_authorities field of the CertificateRequest handshake message,
which essentially means that they do support TLS client certificates
_at_all_ (in a fashion compliant to the  TLS protocol spec).

 
-Martin