IETF Logo Mail Archive

Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 04 December 2014 07:42 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6BC1A88CB for <tls@ietfa.amsl.com>; Wed, 3 Dec 2014 23:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 LT4koOd5NgFj for <tls@ietfa.amsl.com>; Wed, 3 Dec 2014 23:42:19 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C72F1A0074 for <tls@ietf.org>; Wed, 3 Dec 2014 23:42:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1417678939; x=1449214939; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7qJ/m2nH2nkBj5Hfbb17h4U7KjWxfSfqd4mxl3Xri64=; b=Vh2gSKTm8MehgzNUH4NM+s9Fev8TeKqCeIF62DHmUdGKkpifgkSbtEKF 93nbH8RHxByhNpuFhZpv4GkcUyvsI5dKy+BPjceb+sDOlAR19dFg7hXU7 7V9UbxR8Re3kNvPt5IzW/l56fNC9mKYy9zkKBDXcnYbD8PPVH/DleMbKa A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="294835745"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Dec 2014 20:42:15 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 4 Dec 2014 20:42:14 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] WG adoption: draft-nir-tls-rfc4492bis
Thread-Index: AdAPldG0njcyRjMCRke2jv01iiBgXg==
Date: Thu, 04 Dec 2014 07:42:13 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9FAA0F@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vp7bnKSQaXbyKXTA3TuRKgPrGBk
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Thu, 04 Dec 2014 07:42:23 -0000

Jeffrey Walton <noloader@gmail.com> yes:

>Wouldn't that put certificate parameters (like signing algorithms) under the
>purview of PKIX WG?

Yes.  That's the problem with this requirement (which others have already
pointed out), it's a layering violation.  The TLS stack should not be
dictating terms to the PKI implementation or the CA.

That's not to say that PKIX doesn't do the same thing.  Their CMP spec
requires that the cert-transport layer pull apart the certificates that are
being communicated, extract the signature algorithm from the cert, and
authenticate the messaging using the algorithm used to sign the cert. 

Both are a me-centric worldview, for TLS it's "the PKI does what the transport
tells it to", for PKIX it's "the transport does what the PKI tells it to".  If
RFC 1958 gets updated at some point they should add "Redde Caesari quae sunt
Caesaris" as a design principle.

Peter.

v2.23.0 | Report a Bug | By Email