Re: [TLS] Update spec to match current practices for certificate chain order

mrex@sap.com (Martin Rex) Thu, 07 May 2015 17:51 UTC

Return-Path: <mrex@sap.com>
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 118FC1ACE77 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 10:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.951
X-Spam-Level:
X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 qK_FLH7rY2sx for <tls@ietfa.amsl.com>; Thu, 7 May 2015 10:51:38 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E41ACE49 for <tls@ietf.org>; Thu, 7 May 2015 10:51:38 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 30FFD2AB58; Thu, 7 May 2015 19:51:36 +0200 (CEST)
X-purgate-ID: 152705::1431021096-00005316-EC567911/0/0
X-purgate-size: 2249
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id DB86443A82; Thu, 7 May 2015 19:51:35 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CEE581B2DA; Thu, 7 May 2015 19:51:35 +0200 (CEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Thu, 7 May 2015 19:51:35 +0200 (CEST)
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: <20150507175135.CEE581B2DA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-Nw-_l4GH6rr0bNIAK3wwLX9mq8>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 07 May 2015 17:51:40 -0000

Peter Gutmann wrote:
> Martin Rex <mrex@sap.com> writes:
>> 
>>PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify
>>the end-entity certificate.  In TLS, the identification is the first position
>>in certificate_list.  So it is not possible to "blindly reuse" the code with
>>respect to identifying the end-entity certificate.
> 
> Yes it is, as I mentioned in my previous message my code looks for the server
> FQDN/whatever and uses the cert that contains that as the leaf cert.  It's the
> same process that's used for IssuerAndSerialNumber, SCEP client IDs, and
> various other things, "find the cert for the identified party, then follow
> parent links to build the chain".

I'm sorry, but I fail to understand what you mean.  The TLS protocol
layer explicitly has no business whatsoever with names in certificates,
that has been spelled out clearly in all existing TLS specs.
A TLS client should not know or care about the hostname of the server
it is talking to, and there is no requirement what kind of stuff is
contained in the server's certificate.  Our TLS client does _not_ know
the server's hostname (it gets a connected socket).

  https://tools.ietf.org/html/rfc5246#page-5

                                 the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
*> exchanged are left to the judgment of the designers and implementors
*> of protocols that run on top of TLS.


As I said, it is impossible for the client to use the PKCS#7/CMS
approach to locate the client certificate.

The Definition of the TLS Certificate PDU has always contained this
paragraph:

  https://tools.ietf.org/html/rfc6101#section-5.6.2
  https://tools.ietf.org/html/rfc5246#page-48

   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
   vector because PKCS #6 [PKCS6] extended certificates are not used.
   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
   of parsing the list more difficult.


Personally, I find it quite appalling how many broken TLS
implementations out there fail to properly encode an ordered list
of certificates into the Certificate handshake message.


-Martin