Re: [TLS] TLS 1.3 certificate delegation?

mrex@sap.com (Martin Rex) Fri, 08 November 2013 16:52 UTC

Return-Path: <mrex@sap.com>
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 4061011E8186 for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 08:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.164
X-Spam-Level:
X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgHlp4kQ0ujJ for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 08:52:21 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B611E8168 for <tls@ietf.org>; Fri, 8 Nov 2013 08:52:20 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA8GqILw009880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 17:52:18 +0100 (MET)
In-Reply-To: <527CF707.2070000@secunet.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Date: Fri, 08 Nov 2013 17:52:18 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131108165218.1EEB01AA71@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 16:52:25 -0000

Johannes Merkle wrote:
> 
>> It would be a departure from established practice, but, if certificate
>> #3 permits signing, then there's nothing insecure about this certificate
>> chain.  Whoever has the private key associated with certificate #3 is
>> permitted to host the domains described by the common name and
>> subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
>> they're willing to delegate authority to certificate #4, they should be
>> able to.
> 
> It is a bad idea to introduce violations of PKIX standards
> (RFC 5280) in TLS  1.3.

It is actually not a violation of PKIX.  However, behaviour is undefined.

PKIX (rfc5280) inherited this from X.509, and it has been spelled out
in rfc5280-clarifications:

  http://tools.ietf.org/html/rfc6818#section-2

  2. Update to RFC 5280, Section 3.2: "Certification Paths and Trust"


     Add the following paragraph to the end of RFC 5280, Section 3.2:

  | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
  | that use of self-issued certificates and self-signed certificates
  | issued by entities other than CAs are outside the scope of this
  | specification.  Thus, for example, a web server or client might
  | generate a self-signed certificate to identify itself.  These
  | certificates and how a relying party uses them to authenticate
  | asserted identities are both outside the scope of RFC 5280.


"outside the scope of rfc5280".

which essentially means that TLSv1.3 could actually specify
whatever semantics it sees fit.  The problem that may arise, however
is that passing a certification path with such a
"self-issued certificate issued by an entity other than a CA"
to a _vanilla_ PKIX/rfc5280 or X.509 certificate path validation
function might not give you the result that you may be looking
for, likely applying CA checks on the end entity cert above
the proxy cert and aborting path validation with an error.


-Martin