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

[Paul Hoffman <[e-mail]>]

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