Re: [TLS] Certificate validation can of worms

mrex@sap.com (Martin Rex) Tue, 08 April 2014 20:41 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 163101A0412 for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 13:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 PKZhBRBigxl3 for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 13:41:54 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA91A034E for <tls@ietf.org>; Tue, 8 Apr 2014 13:41:54 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s38KfoW1028710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 22:41:50 +0200 (MEST)
In-Reply-To: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com>
To: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Tue, 08 Apr 2014 22:41:50 +0200
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: <20140408204150.9505B1ACB3@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WrjK0UM8J5nwlmI8IujY2Q3Jlaw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Certificate validation can of worms
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: Tue, 08 Apr 2014 20:41:59 -0000

Santosh Chokhani wrote:
> 
> The EKU is generally only applies to the leaf certificate (per X.509
> and RFC 5280) and is not involved in path processing.
> I would think that if EKU is present at least a browser application
> will ensure that the certificate has server auth OID.

There is one central statement in rfc5280/PKIX that you seem to be
unaware of:

https://tools.ietf.org/html/rfc5280#section-6.1

   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.


Whit this  "this profile RECOMMENDS against including such checks"
says explicitly to an TLS implementor: you SHOULD NOT implement any
conformance checks to stuff that is described in section 4 & 5 of
this document.  (so you do not have to read, let alone understand
what all the stuff in that part of the document means).


-Martin