[pkix] Re: [Errata Held for Document Update] RFC5280 ( 8789)
Deb Cooley <[email protected]> Tue, 3 Mar 2026 14:44:11 -0500
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CAGgd1OdDGTR4dcuXr=NCO+jtd==8nsbZSuoCzEp13p3BujQAPA@mail.gmail.com> |
--===============6053451956101160177== Content-Type: multipart/alternative; boundary="000000000000268870064c23ee2c" --000000000000268870064c23ee2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It appears to be. It does raise questions... I'll ask what we should do. Deb On Tue, Mar 3, 2026 at 2:38=E2=80=AFPM Corey Bonnell <Corey.Bonnell=3D [email protected]> wrote: > I'm confused. Isn't this erratum a duplicate of the verified, technical > erratum https://www.rfc-editor.org/errata/eid5802? > > -----Original Message----- > From: RFC Errata System <[email protected]> > Sent: Tuesday, March 3, 2026 12:34 PM > To: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected]; [email protected]= m; > > [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: [pkix] [Errata Held for Document Update] RFC5280 (8789) > > The following errata report has been held for document update 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 > > -------------------------------------- > Status: Held for Document Update > Type: Editorial > > Reported by: Elizabeth Peraza Slator <[email protected]> Date > Reported: 2026-02-28 Held by: Paul Wouters (IESG) > > 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 > ----- > Sec AD (Paul Wouters): Changed to Editorial, as the suggested changes ar= e > in > an ASN.1 comment > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificat= e > 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] > --000000000000268870064c23ee2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>It appears to be.=C2=A0 It does raise questions...=C2= =A0 I'll ask what we should do.</div><div><br></div><div>Deb</div></div= ><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas= s=3D"gmail_attr">On Tue, Mar 3, 2026 at 2:38=E2=80=AFPM Corey Bonnell <C= orey.Bonnell=3D<a href=3D"mailto:[email protected]">40digicert.= [email protected]</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">I'm confused. Isn't this erratum a duplicate of t= he verified, technical <br> erratum <a href=3D"https://www.rfc-editor.org/errata/eid5802" rel=3D"norefe= rrer" target=3D"_blank">https://www.rfc-editor.org/errata/eid5802</a>?<br> <br> -----Original Message-----<br> From: RFC Errata System <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>><br> Sent: Tuesday, March 3, 2026 12:34 PM<br> To: <a href=3D"mailto:[email protected]" target=3D"_blank">elizabe= [email protected]</a>; <a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>; <a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>; <br> <a href=3D"mailto:[email protected]" target=3D"_blank">stephen.farr= [email protected]</a>; <a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>; <a href=3D"mailto:[email protected]= m" target=3D"_blank">[email protected]</a>; <br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> Cc: <a href=3D"mailto:[email protected]" target=3D"_blank">paul.wouters= @aiven.io</a>; <a href=3D"mailto:[email protected]" target=3D"_blank">iesg@ietf= .org</a>; <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a>; <br> <a href=3D"mailto:[email protected]" target=3D"_blank">rfc-editor@r= fc-editor.org</a><br> Subject: [pkix] [Errata Held for Document Update] RFC5280 (8789)<br> <br> The following errata report has been held for document update for RFC5280, = <br> "Internet X.509 Public Key Infrastructure Certificate and Certificate = <br> 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"noreferrer" ta= rget=3D"_blank">https://www.rfc-editor.org/errata/eid8789</a><br> <br> --------------------------------------<br> Status: Held for Document Update<br> Type: Editorial<br> <br> Reported by: Elizabeth Peraza Slator <<a href=3D"mailto:elizabethpslator= @gmail.com" target=3D"_blank">[email protected]</a>> Date <br> Reported: 2026-02-28 Held by: Paul Wouters (IESG)<br> <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: digitalSignature,<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: digitalSignature<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: digitalSignature,<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: digitalSignature<br> =C2=A0 =C2=A0-- and/or keyAgreement<br> Notes:<br> <br> The proposed change removes the WWW part of the description. In practice th= ese <br> object identifiers are used for server and client applications, but not <br= > necessarily web applications. In particular:<br> - openssl verification considers them unconditionally even if the server is= <br> not a web server or the client a web client<br> - There is no object identifier that can be used for protocols like SMTP, <= br> IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed= <br> with the identifiers for WWW<br> - Standards like common criteria assume that these object identifiers are f= or <br> 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/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> =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: digitalSignature,<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: digitalSignature<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: digitalSignature,<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: digitalSignature<br> =C2=A0 =C2=A0-- and/or keyAgreement<br> Notes:<br> <br> The proposed change removes the WWW part of the description. In practice th= ese <br> object identifiers are used for server and client applications, but not <br= > necessarily web applications. In particular:<br> - openssl verification considers them unconditionally even if the server is= <br> not a web server or the client a web client<br> - There is no object identifier that can be used for protocols like SMTP, <= br> IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed= <br> with the identifiers for WWW<br> - Standards like common criteria assume that these object identifiers are f= or <br> 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/MMO/PP/-442= -/#FCS_TLSC_EXT.1.1</a><br> <br> Report New Errata<br> <br> Notes<br> -----<br> Sec AD (Paul Wouters): Changed to Editorial,=C2=A0 as the suggested changes= are in <br> an ASN.1 comment<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: Internet X.50= 9 Public Key Infrastructure Certificate and <br> 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. <br> Housley, W. Polk<br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<br> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Public-Key Infrast= ructure (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">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> --000000000000268870064c23ee2c-- --===============6053451956101160177== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBraXgtbGVhdmVAaWV0Zi5vcmcK --===============6053451956101160177==--