Re: [keyassure] Bare keys again

Martin Rex <mrex@sap.com> Mon, 21 March 2011 21:59 UTC

Return-Path: <mrex@sap.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6133A68ED for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 14:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level:
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 fiBCb8E28kdN for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 14:59:32 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F1F9D3A68E4 for <keyassure@ietf.org>; Mon, 21 Mar 2011 14:59:31 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2LM13hQ022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2011 23:01:04 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103212201.p2LM13oI018636@fs4113.wdf.sap.corp>
To: paul@xelerance.com
Date: Mon, 21 Mar 2011 23:01:03 +0100
In-Reply-To: <alpine.LFD.1.10.1103211736000.28224@newtla.xelerance.com> from "Paul Wouters" at Mar 21, 11 05:40:52 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Bare keys again
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2011 21:59:38 -0000

Paul Wouters wrote:
> 
> Thank you for pointing this out. Only now I understand what the objection
> is. Rereading 6066, it does seem to indicate the EE cert was not meant
> to be omitted, though the handshake diagram in 5246 seems to suggest it
> can be omitted. I will do some more re-reading of 5246.

The diagram   http://tools.ietf.org/html/rfc5246#page-36

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake

   * Indicates optional or situation-dependent messages that are not
   always sent.

means that in some handshake the entire "Server Certificate" might
be omitted, and the definition of the "Server Certificate" handshake
message tells you, which handshakes or situations these are.

   http://tools.ietf.org/html/rfc5246#section-7.4.2


There is a proposal to omit a pre-agreed server certificate (chain) from
the TLS handshake here:

  http://tools.ietf.org/html/draft-ietf-tls-cached-info-09


but the document got stuck on the algorithm agility discussions for
this proposal a while ago...

-Martin