Re: [keyassure] Bare keys again

Paul Wouters <paul@xelerance.com> Mon, 21 March 2011 20:00 UTC

Return-Path: <paul@xelerance.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 0AB7728C0F4 for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 13:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599]
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 vgtE3LDzfU4D for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 13:00:41 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4EFDF28C164 for <keyassure@ietf.org>; Mon, 21 Mar 2011 13:00:33 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 14916C582; Mon, 21 Mar 2011 16:02:05 -0400 (EDT)
Date: Mon, 21 Mar 2011 16:02:04 -0400
From: Paul Wouters <paul@xelerance.com>
To: Martin Rex <mrex@sap.com>
In-Reply-To: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp>
Message-ID: <alpine.LFD.1.10.1103211557590.20162@newtla.xelerance.com>
References: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: keyassure@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [keyassure] Bare keys again
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 20:00:48 -0000

On Mon, 21 Mar 2011, Martin Rex wrote:

> See http://tools.ietf.org/html/rfc5246#section-7.4.2
>
>   When this message will be sent:
>
>      The server MUST send a Certificate message whenever the agreed-
>      upon key exchange method uses certificates for authentication
>      (this includes all key exchange methods defined in this document
>      except DH_anon).  This message will always immediately follow the
>      ServerHello message.
>
> which part of the "MUST send" is unclear to you?
>
> What might be slighly misleading in that section is that it
> defines a handshake message that is used in two situations
> (Server Certificate and Client Certificate) and the semantics of an
> empty Certificate handshake message is only defined for the
> "Client Certificate" handshake message, but _NOT_ for the Server Certificate
> handshake message.

Section 7 of 5246 shows me:

     Client                                               Server

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

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

To me this seems to say that "Certificate*" on the server side could
be omitted in situation-dependent messages.

Paul