The requirements say that: The OS shall validate the extendedKeyUsage field according to the following rules:
Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
When looking at the source RFC for this requirement, we found that there was no such requirement that the IETF levied. We proposed an errata to RFC5802 to see if we could standardize the RFC so that all servers follow the RFC.
https://www.rfc-editor.org/errata/eid5802
What is clear from the conversation is that most of the IETF experts assume that either the TLS protocol standards should require specific EKUs. Or if HTTP wants to be "different", than the HTTP (/2 ?) standards, it should require its own. And if neither says anything in their documents, then those EKUs are not a requirement, but simply an option that is implementation or even deployment specific.
table 3-1 also mandates id-kp-serverAuth even though this is a general recommendation for TLS.
However, it states a weak justification by saying that some client applications may require this and thus fail if serverAuth is not there. So that goes back to a deployment specific requirement. It doesn't say that the client must fail the connection. It's that some may. So it recommends creating certificates with that option just in case.
It seems that the correct thing is to recognize that EKU fields are optional when accessing various server services such as ldaps, imaps, syslog, secure pop3, etc.
The requirements say that: The OS shall validate the extendedKeyUsage field according to the following rules:
When looking at the source RFC for this requirement, we found that there was no such requirement that the IETF levied. We proposed an errata to RFC5802 to see if we could standardize the RFC so that all servers follow the RFC. https://www.rfc-editor.org/errata/eid5802
This lead to conversation in the working group: https://mailarchive.ietf.org/arch/msg/pkix/DQQQ-lujoXWGKMLVSlYmDHzzP9E
What is clear from the conversation is that most of the IETF experts assume that either the TLS protocol standards should require specific EKUs. Or if HTTP wants to be "different", than the HTTP (/2 ?) standards, it should require its own. And if neither says anything in their documents, then those EKUs are not a requirement, but simply an option that is implementation or even deployment specific.
Further research points to this as a possible origin of the mandate: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
table 3-1 also mandates id-kp-serverAuth even though this is a general recommendation for TLS.
However, it states a weak justification by saying that some client applications may require this and thus fail if serverAuth is not there. So that goes back to a deployment specific requirement. It doesn't say that the client must fail the connection. It's that some may. So it recommends creating certificates with that option just in case.
It seems that the correct thing is to recognize that EKU fields are optional when accessing various server services such as ldaps, imaps, syslog, secure pop3, etc.