Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

1 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.