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

[Tim Hollebeek <[e-mail]>]

I think it should be rejected as well. I actually have lots of strong feelings on this issue, but the original text is not wrong.

-Tim
________________________________
From: Michael StJohns <[e-mail]>
Sent: Tuesday, March 3, 2026 12:29 PM
To: [e-mail] <[e-mail]>
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 “WWW” from the comment sure, but please mark this as “Editorial" as the suggested changes are in an ASN.1 comment ;)
>
> 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]
> _______________________________________________
> pkix mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


_______________________________________________
pkix mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]