Both id-kp-serverAuth and id-kp-clientAuth MUST be set

[georgi-lozev]

Hello friends.

Looking into https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#44-extended-key-usage we have the following sentences.

When included, fields id-kp-serverAuth and id-kp-clientAuth MUST be set.

while if we check the reference https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#appendix-a-x509-field-reference we have

Extended Key Usage	id-kp-serverAuth	This field may be set for either leaf or signing certificates.
Extended Key Usage	id-kp-clientAuth	This field may be set for either leaf or signing certificates.

Does anyone recall the reasoning behind both id-kp-serverAuth and id-kp-clientAuth being present?

Do you see as a viable use case to have only TLS Web Client Authentication in case you don't plan to use it for TLS Web Server Authentication ?

[andrewpmartinez]

Do you see as a viable use case to have only TLS Web Client Authentication in case you don't plan to use it for TLS Web Server Authentication ?

This is a use case in one of my other projects where strong identities are quired on both ends of an mTLS connection, but clients will never act as a TSL-backed server. Having both flags set is convenient as it absolves the SPIFFE implementor of needing to know or consider the use of the certificates. However, it violated the principle of least privilege (unsure if that is something cared about here).

Client authentication backed by client certificates does not get as much fanfare on the web due to its higher requirements of coordination and management (CSRs, OCSP/CRLs, CA chains, etc.), but a new wave of strong identity connectivity providers emerge in/around the Zero Trust that are starting to make it more common.

[georgi-lozev]

However, it violated the principle of least privilege (unsure if that is something cared about here).
Yes, that's our way of thinking.

[azdagron]

I don't have the history on why that requirement is in the spec. @evan2645, @spikecurtis , do either of you recall? The justification should probably be somewhere in the spec.

[evan2645]

I remember two primary reasons for this:

• Conceptually, an SVID proves an identity, and dictating what said identity can and can't be used for doesn't fit well with the SPIFFE model. It is up to the workload to use its identity how it pleases. Setting constraints on what a specific identity can do is an authorization problem.
• SPIFFE strongly encourages mutual authentication. Issuing an identity to a workload that is only good for one or another side of the conversation significantly inhibits this. What happens when the author of a server software needs to introduce a call to an external service?

I think that, in general, X.509 is powerful and has facilities meant to address a wide variety of use cases. Some of them are orthogonal to SPIFFE and can safely co-exist/be supported (e.g. DNS SAN or Subject). Some of them are directly related to SPIFFE, or directly influence behavior that is important to SPIFFE. In the case of the latter, IMO, it's important to have strong definition, and behavior that will not surprise users.

[andrewpmartinez]

A mindset shift that just happened for me is that the SPIFFE spec is independent of implementation-specific decisions. So where the SPIFFE spec is less strict (may have client/server key uses), it allows specific implementations to guide users towards being more strict (i.e. restricting key usage).