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

--===============1106881861815617697==
Content-Type: multipart/alternative; boundary="000000000000708941064c265732"

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

Change the current one to rejected - duplicate.  Leave the other one alone.


Neither errata has any meaningful real world impact however they=E2=80=99re
resolved.

Mike

On Tue, Mar 3, 2026 at 17:33 Deb Cooley <[email protected]> wrote:

> 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]>=
 wrote:
>
>> 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 b=
y
>> 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 err=
ata.
>>
>> 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]
>>
> _______________________________________________
> pkix mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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

<div dir=3D"auto">Change the current one to rejected - duplicate.=C2=A0 Lea=
ve the other one alone. =C2=A0=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Neither errata has any meaningful real world impact however th=
ey=E2=80=99re resolved. =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Mike</div><div dir=3D"auto"><br><div class=3D"gmail_quote gmail_quot=
e_container" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar=
 3, 2026 at 17:33 Deb Cooley &lt;<a href=3D"mailto:[email protected]">de=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>And as Corey has pointed out I validated the same basi=
c 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;H=
FDU&#39;.=C2=A0 That&#39;s fantastic.</div></div><div dir=3D"ltr"><div><br>=
</div><div>Deb</div></div><br><div class=3D"gmail_quote"><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]" target=3D"_blank">[email protected]=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Caution: dead horse 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>
_______________________________________________<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></div>

--000000000000708941064c265732--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============1106881861815617697==--