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

Jim Schaad <> Tue, 06 August 2019 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52E2312008C for <>; Tue, 6 Aug 2019 15:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6KjZgKK6yqoS for <>; Tue, 6 Aug 2019 15:57:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE56012008B for <>; Tue, 6 Aug 2019 15:57:35 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Aug 2019 15:57:28 -0700
From: Jim Schaad <>
To: <>, 'Russ Housley' <>
CC: "'Roman D. Danyliw'" <>, 'Ben Kaduk' <>, 'IETF PKIX' <>
References: <> <> <>
In-Reply-To: <>
Date: Tue, 6 Aug 2019 15:57:27 -0700
Message-ID: <03e501d54caa$537426d0$fa5c7470$>
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: []
Archived-At: <>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Aug 2019 22:57:38 -0000

-----Original Message-----
From: pkix <> On Behalf Of Martin Rex
Sent: Tuesday, August 6, 2019 2:22 PM
To: Russ Housley <>
Cc: Roman D. Danyliw <>rg>; Ben Kaduk <>du>; IETF PKIX
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)

Russ Housley <> 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



pkix mailing list