How do I constrain Windows Smartcards for AD Authentication so that "anyExtendedKeyUsage" is not implied?

Question

This document describes how there are 3 ways to constrain a SmartCard certificate

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

• All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.
• All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate. Root trust point EKU field asserts Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).
• All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension. The Federal Common Policy CA certificate does not assert an EKU; therefore all application policies are implied.

Does this mean I need a dedicated SmartCard PKI in my environment just to constrain Smartcards to authentication?

Is there any way I can have a Root CA defined for all usages + smartcard, and also have a sub-ca dedicated to smartcards so I can trick the AD validation process?

Answer 1

On a general basis, you cannot enforce a constraint such as "should be used only for smartcard logon". This is supposed to be the role of the Extended Key Usage certificate extension; see RFC 5280, section 4.2.1.12:

If the extension is present, then the certificate MUST only be used for one of the purposes indicated.

But this relies on all applications which validate certificates to actually check the EKU and enforce its contents (an application is supposed to check whether the EKU is there and contains its own OID, or the special anyEKU OID; or, at least, the EKU extension should be absent, if the application does not have a specific OID for itself). In practice, applications do not perform such checks. Some applications will do such processing, but you cannot reliably expect all applications to do it, even if you restrict yourself to the pure Microsoft world.

To enforce separation of roles, you really need several PKI (EKU ought to do it, but in practice it does not, which is sad). To some extent, you could make "one" PKI (i.e. one root) and use distinct sub-CA, and you set the subordinate CA themselves as roots (e.g. you would push the sub-CA specific for smartcard issuance as the "root" in the NTAuth store on the Active Directory server). Such sub-CA are root CA in disguise, so you had better handle them as such (e.g. make them long-lived).

In general, enforcing non-usage of issued certificates is a fruitless quest. To cover yourself in a legal way, it suffices to publish a Certification Policy Statement, duly linked to from the Certificate Policies extension in the certificate, where you state in plain words that the certificates are meant for smartcard logon only. It is not needed (and not really possible either with 100% reliability) that you arrange for all other existing software to reject your certificates. Ultimately, any application can validate certificates as it sees fit.

Answer 2

Is your goal only to have windows select the correct certificate for smart card logon? To differentiate between a signature and an authentication certificate? If that is your goal and windows is the environment you are primarily concerned with, then no you don't need a separate PKI. Put smart card logon and TLS client auth in the EKU of the user's authentication cert, and omit those from the EKU in their signature certificate. Note that you must include EKU in the signature certificate or they could be matched for smart card logon per the 'any eku' treatment.

That's an interesting link you posted, I always thought Windows would work with only the smart card logon EKU, but that article says you must include the TLS client auth EKU..? Feels odd to me and I think I have seen other TechNet articles that contradict this, but I'm too sleepy to go looking. Folks generally only want one auth certificate and thus would naturally include both of these in the auth certificate.

Finally, worth noting that Thomas is also making a valid point across all the software that could consume your certificates - not all software will process the EKU the way you would like - but Windows does handle this case reasonably well.