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

Jim Schaad <ietf@augustcellars.com> Tue, 06 August 2019 22:57 UTC

Return-Path: <ietf@augustcellars.com>
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 52E2312008C for <pkix@ietfa.amsl.com>; Tue, 6 Aug 2019 15:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 6KjZgKK6yqoS for <pkix@ietfa.amsl.com>; Tue, 6 Aug 2019 15:57:36 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE56012008B for <pkix@ietf.org>; Tue, 6 Aug 2019 15:57:35 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Aug 2019 15:57:28 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <mrex@sap.com>, 'Russ Housley' <housley@vigilsec.com>
CC: "'Roman D. Danyliw'" <rdd@cert.org>, 'Ben Kaduk' <kaduk@mit.edu>, 'IETF PKIX' <pkix@ietf.org>
References: <20190806155608.27C2CB82482@rfc-editor.org> <AEBEC96E-3645-4A69-9E42-EA7DF15AE277@vigilsec.com> <20190806212146.A3010404B@ld9781.wdf.sap.corp>
In-Reply-To: <20190806212146.A3010404B@ld9781.wdf.sap.corp>
Date: Tue, 6 Aug 2019 15:57:27 -0700
Message-ID: <03e501d54caa$537426d0$fa5c7470$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGoMs2KwwQUs4FSoAriW+ooo9s5HAFPjzDGAjAiGXunLPESoA==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/chNbSd2n0CrAHR1kwAoVTG1I0y4>
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: Tue, 06 Aug 2019 22:57:38 -0000


-----Original Message-----
From: pkix <pkix-bounces@ietf.org>; On Behalf Of Martin Rex
Sent: Tuesday, August 6, 2019 2:22 PM
To: Russ Housley <housley@vigilsec.com>;
Cc: Roman D. Danyliw <rdd@cert.org>;; Ben Kaduk <kaduk@mit.edu>;; IETF PKIX
<pkix@ietf.org>;
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)

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.

[JLS]  I would consider this to be correct behavior.  My reading is that
id-kp-clientAuth is going to be in the client certificate that is being used
to authenticate to the server.  No a statement that the server wants or can
do client auth.

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.

[JLS]  I have no opinion on this one way or the other

Jim


-Martin

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix