[pkix] Re: [Technical Errata Reported] RFC5280 (8789 )
Tim Hollebeek <[email protected]> Tue, 3 Mar 2026 19:32:59 +0000
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <SN7PR14MB649277FF0B9F8D7824393895837FA@SN7PR14MB6492.namprd14.prod.outlook.com> |
--===============2845107245731276787== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SN7PR14MB649277FF0B9F8D7824393895837FASN7PR14MB6492namp_" --_000_SN7PR14MB649277FF0B9F8D7824393895837FASN7PR14MB6492namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think it should be rejected as well. I actually have lots of strong feeli= ngs on this issue, but the original text is not wrong. -Tim ________________________________ From: Michael StJohns <[email protected]> Sent: Tuesday, March 3, 2026 12:29 PM To: [email protected] <[email protected]> Subject: [pkix] Re: [Technical Errata Reported] RFC5280 (8789) What Sean said. I'd actually be inclined to reject the errata as a) it is in a comment, and b) the fact that people are using this for non-WWW stuff does not change the behavior for WWW stuff. Mike On 3/3/2026 11:47, Sean Turner wrote: > If we want to remove the =93WWW=94 from the comment sure, but please mark= this as =93Editorial" as the suggested changes are in an ASN.1 comment ;) > > 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 document= 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 R= evocation 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 practic= e 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 serve= r is not a web server or the client a web client >>> - There is no object identifier that can be used for protocols like SMT= P, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deplo= yed with the identifiers for WWW >>> - Standards like common criteria assume that these object identifiers a= re 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 practic= e 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 serve= r is not a web server or the client a web client >>> - There is no object identifier that can be used for protocols like SMT= P, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deplo= yed with the identifiers for WWW >>> - Standards like common criteria assume that these object identifiers a= re 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 Certific= ate 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] > _______________________________________________ > 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] --_000_SN7PR14MB649277FF0B9F8D7824393895837FASN7PR14MB6492namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <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"> I think it should be rejected as well. I actually have lots of strong feeli= ngs on this issue, but the original text is not wrong.</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> Michael StJohns <m= [email protected]><br> <b>Sent:</b> Tuesday, March 3, 2026 12:29 PM<br> <b>To:</b> [email protected] <[email protected]><br> <b>Subject:</b> [pkix] Re: [Technical Errata Reported] RFC5280 (8789)</font= > <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">What Sean said. I'd actually be inclined to = reject the errata as a) it <br> is in a comment, and b) the fact that people are using this for non-WWW <br= > stuff does not change the behavior for WWW stuff.<br> <br> Mike<br> <br> On 3/3/2026 11:47, Sean Turner wrote:<br> > If we want to remove the =93WWW=94 from the comment sure, but please m= ark this as =93Editorial" as the suggested changes are in an ASN.1 com= ment ;)<br> ><br> > spt<br> ><br> >> On Feb 27, 2026, at 21:23, Paul Hoffman <[email protected]>= ; wrote:<br> >><br> >> This errata report is correct and should be marked as "hold f= or document 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= Certificate 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">https://= www.rfc-editor.org/errata/eid8789</a><br> >>><br> >>> --------------------------------------<br> >>> Type: Technical<br> >>> Reported by: Elizabeth Peraza Slator <elizabethpslator@gmai= l.com><br> >>><br> >>> Section: GLOBAL<br> >>><br> >>> Original Text<br> >>> -------------<br> >>> Section 4.2.1.12 says:<br> >>><br> >>> id-kp-serverAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 1 }<br> >>> -- TLS WWW server authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature,<br> >>> -- keyEncipherment or keyAgreement<br> >>><br> >>> id-kp-clientAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 2 }<br> >>> -- TLS WWW client authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature<br> >>> -- and/or keyAgreement<br> >>> It should say:<br> >>><br> >>> id-kp-serverAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 1 }<br> >>> -- TLS server authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature,<br> >>> -- keyEncipherment or keyAgreement<br> >>><br> >>> id-kp-clientAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 2 }<br> >>> -- TLS client authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature<br> >>> -- and/or keyAgreement<br> >>> Notes:<br> >>><br> >>> The proposed change removes the WWW part of the description. I= n practice these object identifiers are used for server and client applicat= ions, 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= like 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 iden= tifiers are for generic server and clients [0].<br> >>><br> >>> [0]. <a href=3D"https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_T= LSC_EXT.1.1">https://www.niap-ccevs.org/MMO/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> >>> id-kp-serverAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 1 }<br> >>> -- TLS WWW server authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature,<br> >>> -- keyEncipherment or keyAgreement<br> >>><br> >>> id-kp-clientAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 2 }<br> >>> -- TLS WWW client authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature<br> >>> -- and/or keyAgreement<br> >>> It should say:<br> >>><br> >>> id-kp-serverAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 1 }<br> >>> -- TLS server authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature,<br> >>> -- keyEncipherment or keyAgreement<br> >>><br> >>> id-kp-clientAuth &nbs= p; OBJECT IDENTIFIER ::=3D { id-k= p 2 }<br> >>> -- TLS client authentication<br> >>> -- Key usage bits that may be consistent: di= gitalSignature<br> >>> -- and/or keyAgreement<br> >>> Notes:<br> >>><br> >>> The proposed change removes the WWW part of the description. I= n practice these object identifiers are used for server and client applicat= ions, 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= like 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 iden= tifiers are for generic server and clients [0].<br> >>><br> >>> [0]. <a href=3D"https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_T= LSC_EXT.1.1">https://www.niap-ccevs.org/MMO/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 is spam, it<br> >>> will be removed shortly by the RFC Production Center.) Please<= br> >>> use "Reply All" to discuss whether it should be veri= fied or<br> >>> rejected. When a decision is reached, the verifying party<br> >>> will log in to change the status and edit the report, if neces= sary.<br> >>><br> >>> --------------------------------------<br> >>> RFC5280 (draft-ietf-pkix-rfc3280bis-11)<br> >>> --------------------------------------<br> >>> Title &nb= sp; : Internet X.509 Public Key Infrastructure Cert= ificate and Certificate Revocation List (CRL) Profile<br> >>> Publication Date : May 2008<br> >>> Author(s)  = ; : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Po= lk<br> >>> Category = : PROPOSED STANDARD<br> >>> Source &n= bsp; : Public-Key Infrastructure (X.509)<br> >>> Stream &n= bsp; : IETF<br> >>> Verifying Party : IESG<br> >> _______________________________________________<br> >> pkix mailing list -- [email protected]<br> >> To unsubscribe send an email to [email protected]<br> > _______________________________________________<br> > pkix mailing list -- [email protected]<br> > To unsubscribe send an email to [email protected]<br> <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_SN7PR14MB649277FF0B9F8D7824393895837FASN7PR14MB6492namp_-- --===============2845107245731276787== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBraXgtbGVhdmVAaWV0Zi5vcmcK --===============2845107245731276787==--