[pkix] Re: [Technical Errata Reported] RFC5280 (8789 )
Paul Wouters <[email protected]> Tue, 3 Mar 2026 12:34:06 -0500
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CAGL5yWa6pjpyU=1v8fXjiMCQ005+Vaafj+qRkABbLV62+WkKzw@mail.gmail.com> |
--===============7106730869736036830== Content-Type: multipart/alternative; boundary="000000000000e4907d064c221c4a" --000000000000e4907d064c221c4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2026 at 11:47=E2=80=AFAM Sean Turner <[email protected]> wrote: > If we want to remove the =E2=80=9CWWW=E2=80=9D from the comment sure, but= please mark this > as =E2=80=9CEditorial" as the suggested changes are in an ASN.1 comment ;= ) > Done Paul > > spt > > > On Feb 27, 2026, at 21:23, Paul Hoffman <[email protected]> wrote: > > > > This errata report is correct and should be marked as "hold for documen= t > update". > > > > --Paul Hoffman > > > > On 27 Feb 2026, at 17:28, RFC Errata System wrote: > > > >> The following errata report has been submitted for RFC5280, > >> "Internet X.509 Public Key Infrastructure Certificate and Certificate > Revocation List (CRL) Profile". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid8789 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Elizabeth Peraza Slator <[email protected]> > >> > >> Section: GLOBAL > >> > >> Original Text > >> ------------- > >> Section 4.2.1.12 says: > >> > >> id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } > >> -- TLS WWW server authentication > >> -- Key usage bits that may be consistent: digitalSignature, > >> -- keyEncipherment or keyAgreement > >> > >> id-kp-clientAuth OBJECT IDENTIFIER ::=3D { id-kp 2 } > >> -- TLS WWW client authentication > >> -- Key usage bits that may be consistent: digitalSignature > >> -- and/or keyAgreement > >> It should say: > >> > >> id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } > >> -- TLS server authentication > >> -- Key usage bits that may be consistent: digitalSignature, > >> -- keyEncipherment or keyAgreement > >> > >> id-kp-clientAuth OBJECT IDENTIFIER ::=3D { id-kp 2 } > >> -- TLS client authentication > >> -- Key usage bits that may be consistent: digitalSignature > >> -- and/or keyAgreement > >> Notes: > >> > >> The proposed change removes the WWW part of the description. In > practice these object identifiers are used for server and client > applications, but not necessarily web applications. In particular: > >> - openssl verification considers them unconditionally even if the > server is not a web server or the client a web client > >> - There is no object identifier that can be used for protocols like > SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are > deployed with the identifiers for WWW > >> - Standards like common criteria assume that these object identifiers > are for generic server and clients [0]. > >> > >> [0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1 > >> > >> Report New Errata > >> > >> Corrected Text > >> -------------- > >> Section 4.2.1.12 says: > >> > >> id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } > >> -- TLS WWW server authentication > >> -- Key usage bits that may be consistent: digitalSignature, > >> -- keyEncipherment or keyAgreement > >> > >> id-kp-clientAuth OBJECT IDENTIFIER ::=3D { id-kp 2 } > >> -- TLS WWW client authentication > >> -- Key usage bits that may be consistent: digitalSignature > >> -- and/or keyAgreement > >> It should say: > >> > >> id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } > >> -- TLS server authentication > >> -- Key usage bits that may be consistent: digitalSignature, > >> -- keyEncipherment or keyAgreement > >> > >> id-kp-clientAuth OBJECT IDENTIFIER ::=3D { id-kp 2 } > >> -- TLS client authentication > >> -- Key usage bits that may be consistent: digitalSignature > >> -- and/or keyAgreement > >> Notes: > >> > >> The proposed change removes the WWW part of the description. In > practice these object identifiers are used for server and client > applications, but not necessarily web applications. In particular: > >> - openssl verification considers them unconditionally even if the > server is not a web server or the client a web client > >> - There is no object identifier that can be used for protocols like > SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are > deployed with the identifiers for WWW > >> - Standards like common criteria assume that these object identifiers > are for generic server and clients [0]. > >> > >> [0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1 > >> > >> Report New Errata > >> > >> Notes > >> ----- > >> Thank you very much > >> > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". (If it is spam, it > >> will be removed shortly by the RFC Production Center.) Please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party > >> will log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, > R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Stream : IETF > >> Verifying Party : IESG > > > > _______________________________________________ > > pkix mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > --000000000000e4907d064c221c4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail= _quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 3, 2026= at 11:47=E2=80=AFAM Sean Turner <<a href=3D"mailto:[email protected]">sean= @sn3rd.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">If we want to remove the =E2=80=9CWWW=E2=80=9D from the comment = sure, but please mark this as =E2=80=9CEditorial" as the suggested cha= nges are in an ASN.1 comment ;)<br></blockquote><div><br></div><div>Done</d= iv><div><br></div><div>Paul</div><div>=C2=A0</div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex"> <br> spt<br> <br> > On Feb 27, 2026, at 21:23, Paul Hoffman <<a href=3D"mailto:phoffman= @proper.com" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > This errata report is correct and should be marked as "hold for d= ocument update".<br> > <br> > --Paul Hoffman<br> > <br> > On 27 Feb 2026, at 17:28, RFC Errata System wrote:<br> > <br> >> The following errata report has been submitted for RFC5280,<br> >> "Internet X.509 Public Key Infrastructure Certificate and Cer= tificate Revocation List (CRL) Profile".<br> >> <br> >> --------------------------------------<br> >> You may review the report below and at:<br> >> <a href=3D"https://www.rfc-editor.org/errata/eid8789" rel=3D"noref= errer" target=3D"_blank">https://www.rfc-editor.org/errata/eid8789</a><br> >> <br> >> --------------------------------------<br> >> Type: Technical<br> >> Reported by: Elizabeth Peraza Slator <<a href=3D"mailto:elizabe= [email protected]" target=3D"_blank">[email protected]</a>><b= r> >> <br> >> Section: GLOBAL<br> >> <br> >> Original Text<br> >> -------------<br> >> Section 4.2.1.12 says:<br> >> <br> >>=C2=A0 =C2=A0id-kp-serverAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 1 }<br> >>=C2=A0 =C2=A0-- TLS WWW server authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture,<br> >>=C2=A0 =C2=A0-- keyEncipherment or keyAgreement<br> >> <br> >>=C2=A0 =C2=A0id-kp-clientAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 2 }<br> >>=C2=A0 =C2=A0-- TLS WWW client authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture<br> >>=C2=A0 =C2=A0-- and/or keyAgreement<br> >> It should say:<br> >> <br> >>=C2=A0 =C2=A0id-kp-serverAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 1 }<br> >>=C2=A0 =C2=A0-- TLS server authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture,<br> >>=C2=A0 =C2=A0-- keyEncipherment or keyAgreement<br> >> <br> >>=C2=A0 =C2=A0id-kp-clientAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 2 }<br> >>=C2=A0 =C2=A0-- TLS client authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture<br> >>=C2=A0 =C2=A0-- and/or keyAgreement<br> >> Notes:<br> >> <br> >> The proposed change removes the WWW part of the description. In pr= actice these object identifiers are used for server and client applications= , but not necessarily web applications. In particular:<br> >> - openssl verification considers them unconditionally even if the = server is not a web server or the client a web client<br> >> - There is no object identifier that can be used for protocols lik= e SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are = deployed with the identifiers for WWW<br> >> - Standards like common criteria assume that these object identifi= ers are for generic server and clients [0].<br> >> <br> >> [0]. <a href=3D"https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_= EXT.1.1" rel=3D"noreferrer" target=3D"_blank">https://www.niap-ccevs.org/MM= O/PP/-442-/#FCS_TLSC_EXT.1.1</a><br> >> <br> >> Report New Errata<br> >> <br> >> Corrected Text<br> >> --------------<br> >> Section 4.2.1.12 says:<br> >> <br> >>=C2=A0 =C2=A0id-kp-serverAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 1 }<br> >>=C2=A0 =C2=A0-- TLS WWW server authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture,<br> >>=C2=A0 =C2=A0-- keyEncipherment or keyAgreement<br> >> <br> >>=C2=A0 =C2=A0id-kp-clientAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 2 }<br> >>=C2=A0 =C2=A0-- TLS WWW client authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture<br> >>=C2=A0 =C2=A0-- and/or keyAgreement<br> >> It should say:<br> >> <br> >>=C2=A0 =C2=A0id-kp-serverAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 1 }<br> >>=C2=A0 =C2=A0-- TLS server authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture,<br> >>=C2=A0 =C2=A0-- keyEncipherment or keyAgreement<br> >> <br> >>=C2=A0 =C2=A0id-kp-clientAuth=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-kp 2 }<br> >>=C2=A0 =C2=A0-- TLS client authentication<br> >>=C2=A0 =C2=A0-- Key usage bits that may be consistent: digitalSigna= ture<br> >>=C2=A0 =C2=A0-- and/or keyAgreement<br> >> Notes:<br> >> <br> >> The proposed change removes the WWW part of the description. In pr= actice these object identifiers are used for server and client applications= , but not necessarily web applications. In particular:<br> >> - openssl verification considers them unconditionally even if the = server is not a web server or the client a web client<br> >> - There is no object identifier that can be used for protocols lik= e SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are = deployed with the identifiers for WWW<br> >> - Standards like common criteria assume that these object identifi= ers are for generic server and clients [0].<br> >> <br> >> [0]. <a href=3D"https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_= EXT.1.1" rel=3D"noreferrer" target=3D"_blank">https://www.niap-ccevs.org/MM= O/PP/-442-/#FCS_TLSC_EXT.1.1</a><br> >> <br> >> Report New Errata<br> >> <br> >> Notes<br> >> -----<br> >> Thank you very much<br> >> <br> >> Instructions:<br> >> -------------<br> >> This erratum is currently posted as "Reported". (If it i= s spam, it<br> >> will be removed shortly by the RFC Production Center.) Please<br> >> use "Reply All" to discuss whether it should be verified= or<br> >> rejected. When a decision is reached, the verifying party<br> >> will log in to change the status and edit the report, if necessary= .<br> >> <br> >> --------------------------------------<br> >> RFC5280 (draft-ietf-pkix-rfc3280bis-11)<br> >> --------------------------------------<br> >> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Inte= rnet X.509 Public Key Infrastructure Certificate and Certificate Revocation= List (CRL) Profile<br> >> Publication Date=C2=A0 =C2=A0 : May 2008<br> >> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: D. Cooper, S. = Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk<br> >> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAND= ARD<br> >> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Public-Ke= y Infrastructure (X.509)<br> >> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF<br> >> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG<br> > <br> > _______________________________________________<br> > pkix mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a><br> <br> </blockquote></div></div> --000000000000e4907d064c221c4a-- --===============7106730869736036830== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBraXgtbGVhdmVAaWV0Zi5vcmcK --===============7106730869736036830==--