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

Tim Hollebeek <[email protected]> Tue, 3 Mar 2026 20:02:11 +0000
Newsgroups gmane.ietf.x509
Message-ID <SN7PR14MB64921CE6FA13887EEB080F75837FA@SN7PR14MB6492.namprd14.prod.outlook.com>
--===============0089916868706529175==
Content-Language: en-US
Content-Type: multipart/alternative;
 boundary="_000_SN7PR14MB64921CE6FA13887EEB080F75837FASN7PR14MB6492namp_"

--_000_SN7PR14MB64921CE6FA13887EEB080F75837FASN7PR14MB6492namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Right, but for an errata to be appropriate, the original text has to actual=
ly be "in error", not just that "some of us would write something different=
 if we were writing it today". I actually find the comment very useful, as =
it correctly indicates that these EKUs were in fact intended primarily for =
web usage at the time the document was written.

I've actually suggested a few times that we should fix the situation by hav=
ing two new EKUs (one for WebPKI and one for non-web), but there are drawba=
cks to that approach, and it should be a new RFC draft, not an errata.

-Tim
________________________________
From: Paul Hoffman <[email protected]>
Sent: Tuesday, March 3, 2026 2:44 PM
To: [email protected] <[email protected]>
Subject: [pkix] Re: [Technical Errata Reported] RFC5280 (8789)

On 3 Mar 2026, at 11:32, Tim Hollebeek wrote:

> I think it should be rejected as well. I actually have lots of strong fee=
lings on this issue, but the original text is not wrong.

So, some people think it is a comment and thus just editorial, others think=
 it is technical but wrong.

We have a long history of people reading 5280 and 3280 literally, including=
 the comments, particularly comments about key usage. To me, the fact that =
those arguments exist among readers indicates that the comments are in fact=
 part of the spec.

We also know that many CAs will write certificates with id-kp-serverAuth th=
at are not intended for the (undefined) WWW.

--Paul Hoffman

_______________________________________________
pkix mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--_000_SN7PR14MB64921CE6FA13887EEB080F75837FASN7PR14MB6492namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Right, but for an errata to be appropriate, the original text has to actual=
ly be &quot;in error&quot;, not just that &quot;some of us would write some=
thing different if we were writing it today&quot;. I actually find the comm=
ent very useful, as it correctly indicates that these
 EKUs were in fact intended primarily for web usage at the time the documen=
t was written.</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
I've actually suggested a few times that we should fix the situation by hav=
ing two new EKUs (one for WebPKI and one for non-web), but there are drawba=
cks to that approach, and it should be a new RFC draft, not an errata.</div=
>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
-Tim</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Paul Hoffman &lt;phof=
[email protected]&gt;<br>
<b>Sent:</b> Tuesday, March 3, 2026 2:44 PM<br>
<b>To:</b> [email protected] &lt;[email protected]&gt;<br>
<b>Subject:</b> [pkix] Re: [Technical Errata Reported] RFC5280 (8789)</font=
>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">On 3 Mar 2026, at 11:32, Tim Hollebeek wrote:<br>
<br>
&gt; I think it should be rejected as well. I actually have lots of strong =
feelings on this issue, but the original text is not wrong.<br>
<br>
So, some people think it is a comment and thus just editorial, others think=
 it is technical but wrong.<br>
<br>
We have a long history of people reading 5280 and 3280 literally, including=
 the comments, particularly comments about key usage. To me, the fact that =
those arguments exist among readers indicates that the comments are in fact=
 part of the spec.<br>
<br>
We also know that many CAs will write certificates with id-kp-serverAuth th=
at are not intended for the (undefined) WWW.<br>
<br>
--Paul Hoffman<br>
<br>
_______________________________________________<br>
pkix mailing list -- [email protected]<br>
To unsubscribe send an email to [email protected]<br>
</div>
</span></font></div>
</body>
</html>

--_000_SN7PR14MB64921CE6FA13887EEB080F75837FASN7PR14MB6492namp_--


--===============0089916868706529175==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============0089916868706529175==--