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

[Paul Wouters <[e-mail]>]

On Tue, Mar 3, 2026 at 11:47 AM Sean Turner <[e-mail]> wrote:

> If we want to remove the “WWW” from the comment sure, but please mark this
> as “Editorial" as the suggested changes are in an ASN.1 comment ;)
>

Done

Paul


>
> spt
>
> > On Feb 27, 2026, at 21:23, Paul Hoffman <[e-mail]> 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
> 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 <[e-mail]>
> >>
> >> Section: GLOBAL
> >>
> >> Original Text
> >> -------------
> >> Section 4.2.1.12 says:
> >>
> >>   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
> >>   -- TLS WWW server authentication
> >>   -- Key usage bits that may be consistent: digitalSignature,
> >>   -- keyEncipherment or keyAgreement
> >>
> >>   id-kp-clientAuth             OBJECT IDENTIFIER ::= { 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 ::= { id-kp 1 }
> >>   -- TLS server authentication
> >>   -- Key usage bits that may be consistent: digitalSignature,
> >>   -- keyEncipherment or keyAgreement
> >>
> >>   id-kp-clientAuth             OBJECT IDENTIFIER ::= { 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 ::= { id-kp 1 }
> >>   -- TLS WWW server authentication
> >>   -- Key usage bits that may be consistent: digitalSignature,
> >>   -- keyEncipherment or keyAgreement
> >>
> >>   id-kp-clientAuth             OBJECT IDENTIFIER ::= { 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 ::= { id-kp 1 }
> >>   -- TLS server authentication
> >>   -- Key usage bits that may be consistent: digitalSignature,
> >>   -- keyEncipherment or keyAgreement
> >>
> >>   id-kp-clientAuth             OBJECT IDENTIFIER ::= { 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>