[TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?

Alfred Hönes <ah@tr-sys.de> Tue, 21 October 2008 20:00 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9935B3A6A92; Tue, 21 Oct 2008 13:00:53 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2573A6A92 for <tls@core3.amsl.com>; Tue, 21 Oct 2008 13:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.56
X-Spam-Level: *
X-Spam-Status: No, score=1.56 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3]
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 a6hqEcBTC6De for <tls@core3.amsl.com>; Tue, 21 Oct 2008 13:00:52 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 7CA603A6783 for <tls@ietf.org>; Tue, 21 Oct 2008 13:00:51 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA297429244; Tue, 21 Oct 2008 22:00:44 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA27701; Tue, 21 Oct 2008 22:00:43 +0200 (MESZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200810212000.WAA27701@TR-Sys.de>
To: tls@ietf.org
Date: Tue, 21 Oct 2008 22:00:42 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

(A)  hash algorithm agility for the Trusted CA Keys TLS extension

Section 5 of the rfc4366-bis draft contains the following
TLS presentation language definition (from RFC 4366):

---------------------------snip----------------------
      struct {
          TrustedAuthority trusted_authorities_list<0..2^16-1>;
      } TrustedAuthorities;

      struct {
          IdentifierType identifier_type;
          select (identifier_type) {
!             case pre_agreed: struct {};
!             case key_sha1_hash: SHA1Hash;
!             case x509_name: DistinguishedName;
!             case cert_sha1_hash: SHA1Hash;
          } identifier;
      } TrustedAuthority;

      enum {
!         pre_agreed(0), key_sha1_hash(1), x509_name(2),
!         cert_sha1_hash(3), (255)
      } IdentifierType;

      opaque DistinguishedName<1..2^16-1>;
---------------------------snip----------------------

where SHA1Hash is borrowed form Section 5:

---------------------------snip----------------------
      opaque SHA1Hash[20];
---------------------------snip----------------------

This WG is tasked by the IESG & IAB to introduce crypto algorithm
agility into the protocols it supports, whereas the above definition
is still restricted to SHA-1 only.

Therefore, the questions arise:

-  Should the enum IdentifierType be extended with new values
   indicating other hashes for keys and certificates?

-  If yes, adding only SHA-256 (in the spirit of TLS v1.2),
   or adding more variants?


Any opinions?  Further considerations?


(B)  Non-uniqueness of x509_name in Trusted CA Keys TLS extension

The 3rd-to-last paragraph of Section 6 in the -03 version
of the rfc4366-bis draft states:

!  Note also that it is possible that a key hash or a Distinguished Name
!  alone may not uniquely identify a certificate issuer (for example, if
!  a particular CA has multiple key pairs). However, here we assume this
!  is the case following the use of Distinguished Names to identify
!  certificate issuers in TLS.

It seems rather unlikely that this non-uniqueness happens for
a key hash.

But in the course of rekeying or when multiple signature algorithms
(RSA/DSA/ECDSA) are supported by a CA, this non-uniqueness could be
expected to happen rather commonly for x509_name.

-  Is the above quoted assumption still justified?

-  If not, should another common identifier type,
   IssuerAndSerialNumber,
   be introduced to help avoid the ambiguity?
 -or-
-  Does everybody use hashes anyway, such that deprecating
   the x509_name variant might be considered ?

Any opinions?  Further considerations?


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls