Re: [TLS] Certificate validation can of worms

Rob Stradling <rob.stradling@comodo.com> Mon, 07 April 2014 22:03 UTC

Return-Path: <rob.stradling@comodo.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 04FC61A02D1 for <tls@ietfa.amsl.com>; Mon, 7 Apr 2014 15:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
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 o3FvnffRp5_R for <tls@ietfa.amsl.com>; Mon, 7 Apr 2014 15:03:23 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 38A8F1A0298 for <tls@ietf.org>; Mon, 7 Apr 2014 15:03:22 -0700 (PDT)
Received: (qmail 23297 invoked by uid 1000); 7 Apr 2014 22:03:15 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 07 Apr 2014 23:03:15 +0100
Message-ID: <534320A2.5030208@comodo.com>
Date: Mon, 07 Apr 2014 23:03:14 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: mrex@sap.com, Santosh Chokhani <SChokhani@cygnacom.com>
References: <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp>
In-Reply-To: <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GfbklwTcA7Tf0NSXJFMiFqT24FQ
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
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: Mon, 07 Apr 2014 22:03:28 -0000

On 07/04/14 22:30, Martin Rex wrote:
<snip>
> There is *NO* such requirement (to look at EKU) anywhere in rfc5246
> and rfc2818.  The EKU processing within the PKIX certificate path validation
> applies only to path certificates, not to the leaf certificate (because the
> certificate path validation is context-free, i.e. independent of the
> actual usage of the certificate.

Martin, how about RFC6125?

"Representation and Verification of Domain-Based Application Service
  Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
      Certificates in the Context of Transport Layer Security (TLS)
...
1.4.  Applicability

    This document does not supersede the rules for certificate issuance
    or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
    on any point that might also be discussed in this document.
    Furthermore, [PKIX] also governs any certificate-related topic on
    which this document is silent, including but not limited to
    certificate syntax, certificate extensions such as name constraints
    and extended key usage, and handling of certification paths."

<snip>
> Did you notice that the id-kp-serverAuth that is defined in rfc5280
> is strictly limited to HTTP-over-TLS anyway, so would not apply to
> XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.

You mean the "-- TLS WWW server authentication" comment in section 
4.2.1.12?  Or something else?

Would you be happier if "WWW " wasn't in that comment?

>> Similarly, certificate policies and policy constrains extensions should
>> be processed by the client and if the require explicit policy state
>> variable get turned on and the path is not valid for some policy,
>> it must be rejected.
>
> PolicyOIDs are completely meaningless for HTTP-over-TLS.
> Is there *ANY* X-over-TLS specification that gives a meaning
> to any policy OIDs?

Yes.  The CA/Browser Forum EV SSL Guidelines and Baseline Requirements.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online