[TLS] signature_algorithms_cert extension

Matt Caswell <matt@openssl.org> Thu, 18 January 2018 11:30 UTC

Return-Path: <matt@openssl.org>
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 18CBA12D880 for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 03:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0PL6nj0Htmr for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 03:30:01 -0800 (PST)
Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEAE12D80F for <tls@ietf.org>; Thu, 18 Jan 2018 03:30:00 -0800 (PST)
Received: from [10.56.10.6] (ip-45-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 80FFEE790B for <tls@ietf.org>; Thu, 18 Jan 2018 11:29:57 +0000 (UTC)
From: Matt Caswell <matt@openssl.org>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <50eb8f92-b0b2-faab-6f48-14d820480f7d@openssl.org>
Date: Thu, 18 Jan 2018 11:29:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P5k7WtdBaCpwaRxhVG8DYbYDBnQ>
Subject: [TLS] signature_algorithms_cert extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 18 Jan 2018 11:30:03 -0000

The specification of the new signature_algorithms_cert seems somewhat
lacking to me. There is very little description about how it should be
interpreted. About the best I can get from the spec is this:

   The "signature_algorithms_cert" extension applies to signatures in
   certificates and the "signature_algorithms" extension, which
   originally appeared in TLS 1.2, applies to signatures in
   CertificateVerify messages.

But in section 4.4.2.2 we see this:

   All certificates provided by the server MUST be signed by a signature
   algorithm that appears in the "signature_algorithms" extension
   provided by the client, if they are able to provide such a chain (see
   Section 4.2.3).  Certificates that are self-signed or certificates
   that are expected to be trust anchors are not validated as part of
   the chain and therefore MAY be signed with any algorithm.


Is this an oversight? Should this reference "signature_algorithms_cert"
as well/instead?

Some questions:

- Is "signature_algorithms_cert" mandatory to implement for servers? It
does not appear in 9.2 so I am assuming not. There is some text in 4.2.3
 which says what to do if "signature_algorithms_cert" is not present -
which seems to confirm that it is not mandatory for clients at least.

- Are we allowed to ignore "signature_algorithms_cert" if we can't build
a chain and honour its contents?


Matt