IETF Logo Mail Archive

Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt

Martin Rex <mrex@sap.com> Fri, 04 May 2012 22:00 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 9FE6A21F84E1 for <tls@ietfa.amsl.com>; Fri, 4 May 2012 15:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.065
X-Spam-Level:
X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 75c9o9boWlgT for <tls@ietfa.amsl.com>; Fri, 4 May 2012 15:00:50 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF5121F84D8 for <tls@ietf.org>; Fri, 4 May 2012 15:00:50 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44M0k9m009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:00:46 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201205042200.q44M0jY0028398@fs4113.wdf.sap.corp>
To: paul.hoffman@vpnc.org
Date: Sat, 05 May 2012 00:00:45 +0200
In-Reply-To: <1947EFE2-8850-43C3-9590-1D3D44B4B4AA@vpnc.org> from "Paul Hoffman" at May 4, 12 10:58:25 am
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] WGLC for draft-ietf-tls-oob-pubkey-03.txt
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: Fri, 04 May 2012 22:00:51 -0000

Paul Hoffman wrote:
> 
> More importantly, the client auth text added in the last round was:
> 
> 3.5.  Client authentication
> 
>    Client authentication by the TLS server is supported only through
>    authentication of the received client SubjectPublicKeyInfo via an
>    out-of-band method
> 
> This is both wrong and insufficient.

I believe it is acceptable and more correct than your proposed
alternative.

RFC6091 does _not_ permit different certificates types for
client and server, so this will not fit into the extensibility provided
by rfc6091.

If you want to allow an assymetric authentication scheme
(i.e. Server->client OOB in combination with client->server X.509),
then it will be additionally necessary either to seperately negotiate
the type of client "certificate" and require to redefine both,
the CertificateRequest handshake message and the client's
Certificate Handshake message to distinguish which client
certificate type(s) the server is offering and which
client "certificate" type the client has chosen to use.

... at which point it is no longer possible to make this an
extension to rfc6091.

-Martin

v2.23.0 | Report a Bug | By Email