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

--===============4920206598709228931==
Content-Type: multipart/alternative; boundary="0000000000003d94d1064c264a5d"

--0000000000003d94d1064c264a5d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

And as Corey has pointed out I validated the same basic text (errata 5802)
back in 2024.

So now we have the same basic hunk of text both 'validated' and 'HFDU'.
That's fantastic.

Deb

On Tue, Mar 3, 2026 at 3:15=E2=80=AFPM Paul Hoffman <[email protected]> w=
rote:

> Caution: dead horse beating ahead.
>
> On 3 Mar 2026, at 12:02, Tim Hollebeek wrote:
>
> > Right, but for an errata to be appropriate, the original text has to
> actually 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.
>
> "intended primarily for web usage" was true in RFC 2459 in 1999. It was
> much less true in RFC 3280 and then RFC 5280. Also, note that the
> definition says nothing about "intended primarily for".
>
> > I've actually suggested a few times that we should fix the situation by
> having two new EKUs (one for WebPKI and one for non-web), but there are
> drawbacks to that approach, and it should be a new RFC draft, not an erra=
ta.
>
> While I fully agree with "should be a new RFC", I think that RFC should
> likely be titled "EKUs Considered Meaningless" and should deprecate the
> EKUs, not add to the confusion.
>
> --Paul Hoffman
>
> _______________________________________________
> pkix mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--0000000000003d94d1064c264a5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>And as Corey has pointed out I validated the same bas=
ic text (errata 5802) back in 2024.=C2=A0=C2=A0</div><div><br></div><div>So=
 now we have the same basic hunk of text both &#39;validated&#39; and &#39;=
HFDU&#39;.=C2=A0 That&#39;s fantastic.</div><div><br></div><div>Deb</div></=
div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Tue, Mar 3, 2026 at 3:15=E2=80=AFPM Paul Hoffman &lt=
;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Caution: dead ho=
rse beating ahead.<br>
<br>
On 3 Mar 2026, at 12:02, Tim Hollebeek wrote:<br>
<br>
&gt; Right, but for an errata to be appropriate, the original text has to a=
ctually be &quot;in error&quot;, not just that &quot;some of us would write=
 something different if we were writing it today&quot;. I actually find the=
 comment very useful, as it correctly indicates that these EKUs were in fac=
t intended primarily for web usage at the time the document was written.<br=
>
<br>
&quot;intended primarily for web usage&quot; was true in RFC 2459 in 1999. =
It was much less true in RFC 3280 and then RFC 5280. Also, note that the de=
finition says nothing about &quot;intended primarily for&quot;.<br>
<br>
&gt; I&#39;ve actually suggested a few times that we should fix the situati=
on by having two new EKUs (one for WebPKI and one for non-web), but there a=
re drawbacks to that approach, and it should be a new RFC draft, not an err=
ata.<br>
<br>
While I fully agree with &quot;should be a new RFC&quot;, I think that RFC =
should likely be titled &quot;EKUs Considered Meaningless&quot; and should =
deprecate the EKUs, not add to the confusion.<br>
<br>
--Paul Hoffman<br>
<br>
_______________________________________________<br>
pkix mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">pki=
[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a><br>
</blockquote></div>

--0000000000003d94d1064c264a5d--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============4920206598709228931==--