Re: [pkix] [Technical Errata Reported] RFC5280 (5802)

Benjamin Kaduk <kaduk@mit.edu> Thu, 08 August 2019 20:51 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2981120251 for <pkix@ietfa.amsl.com>; Thu, 8 Aug 2019 13:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lIY6rKzdvM85 for <pkix@ietfa.amsl.com>; Thu, 8 Aug 2019 13:51:50 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D46120271 for <pkix@ietf.org>; Thu, 8 Aug 2019 13:51:43 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x78KpZbL008407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Aug 2019 16:51:37 -0400
Date: Thu, 08 Aug 2019 15:51:35 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Rex <mrex@sap.com>
Cc: Russ Housley <housley@vigilsec.com>, nmav@redhat.com, "Roman D. Danyliw" <rdd@cert.org>, IETF PKIX <pkix@ietf.org>
Message-ID: <20190808205134.GI59807@kduck.mit.edu>
References: <20190806155608.27C2CB82482@rfc-editor.org> <AEBEC96E-3645-4A69-9E42-EA7DF15AE277@vigilsec.com> <20190806212146.A3010404B@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190806212146.A3010404B@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/6QXAFvUbW7T4k8cMXFw3_S8IzQQ>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 20:51:52 -0000

Hi Martin,

On Tue, Aug 06, 2019 at 11:21:46PM +0200, Martin Rex wrote:
> Russ Housley <housley@vigilsec.com> wrote:
> > At the time that these values were assigned, TLS was primarily a
> > protocol for WWW security.  It has since been used in may other
> > environments.  I do not see how a change to the comment in the
> > ASN.1 definition will make any real difference, but I do not really
> > have an objection.
> > 
> > I suggest that this be marked as "Hold for Document Update"
> 
> 
> The applicable **STANDARDS** in this area would be
> rfc5246 (TLSv1.2) and rfc2818 (HTTP over TLS), and both are
> **SILENT** on EKU.
> 
> What openssl does is a non-standard, implementation-defined behaviour,
> and I consider it a particularly bad idea trying to rewrite history
> by filing this as an errata !
> 
> 
> I've also seen a public CA (Entrust) issue a TLS server certificate
> which asserted id-kp-serverAuth, but was lacking id-kp-clientAuth.
> I consider such a certificate a stupid clerical error by Entrust.
> 
> Whether TLS client software is willing to use such a certificate
> as TLS client certificate, and whether TLS server software is willing
> to accept such a TLS server certificate as TLS client certificate
> turns out to be *VERY* implementation-specific.
> 
> 
> If changing the limited-applicability comment in rfc5280 for
> id-kp-serverAuth and id-kp-clientAuth at all, then it should also
> include which **application**standards**, if any, gives any meaning
> to these EKUs, and where application standards have *NOT* been
> giving any meaning all the time, the behaviour is implementation-defined
> at best.

We're not changing anything, here; we're just making a note that the
unfortunate people stuck doing a bis of this document should look at this
one issue.  If you think they should also look at an other (related) issue
at the same time, you are free to submit a separate errata report, but I
don't see much reason to think that the two topics should be consolidated
into a single report.

I plan to mark this as HFDU as Russ suggests.

-Ben