0

Assume I have a Root CA that I want to share with hostile untrusted 3rd parties.

Then constrain this root using specific EKUs at the root.

 OID=1.3.6.1.5.5.7.3.4        ; Secure Email 

Next, create a Policy CA (controlled by the root) to restrict the permissions granted to untrusted CAs using Path=1, and Name Constraints (also see this).

Ideal outcome

I would like to issue SMIME certificates that are for signing only, and another for encryption (I understand that support varies on this)

Question

Is it possible to constrain the name, enhanced key usage, and key usage so that a hostile CA I delegate power to can't create HTTPS certificates, and can't create SMIME certificates for other domains?

If the above is true; I think that it's possible to create a SMIME only PKI (please correct me if I'm wrong).

I'm particularly concerned about the ability (or lack thereof) to constrain the key usage field in the CA, so that any properly (or widely deployed client) will see that the CA chain is not permitted to issue HTTPS certificates, and will reject one if offered.

The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:

KeyUsage ::= BIT STRING {
   digitalSignature        (0), -- Needed for SMIME and (EC)DHE TLS implementations
   nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
                                -- Accepted in some TLS implementations if (0) is missing
   keyEncipherment         (2),  Used in RSA based TLS
   dataEncipherment        (3),  Accepted in some TLS implementations if (2) is missing
   keyAgreement            (4),  Accepted in some TLS implementations if (2) is missing
   keyCertSign             (5),
   cRLSign                 (6),
   encipherOnly            (7),
   decipherOnly            (8) }
1

It is possible to create a root CA that cannot be used for SSL by... not using it for SSL !

When a CA issues a certificate for a sub-CA, it does so within the context of a given trust contract. The sub-CA agrees to issues certificates only in accordance to a number of rules which are made explicit in the Certification Policy and the Certificate Practice Statement -- these are legal documents meant for human consumption. If you want a root CA which can be used for S/MIME but not for SSL, then the root CA must state in its CP and CPS that certificates which relate to this root CA must not be used for SSL. In particular, sub-CA take the formal oath never to issue SSL-able certificates (i.e. they won't put machine names in Subject Alt Name extension or in the Common Name part of the SubjectDN; and they will put a critical Extended Key Usage extension which says "for S/MIME only").

In X.509, there are two categories of such "PKI rules":

  1. Rules which are enforced by the validation algorithm. Name Constraints, for instance, can (theoretically) be used to prevent validation of certificates such that the end-entity certificate's name is not part of a namespace of allowed names duly specified in one of the intermediate CA certificates.

  2. Rules which are not enforced by the validation algorithm. The "no SSL" rule would be such a rule.

In pure X.509 theory, there is no actual need for rule enforcement in the validation algorithm; revocation is used to maintain order and punish misbehaving entities. However, in practice, revocation is asynchronous, and too slow to react to "flash attacks". An attacker who wants to run a fake server only needs ten minutes or so to enact considerable mischief; seeing his certificate revoked two days later won't deter him. This is why a number of PKI rules are now enforced at the validation level, first of which being incarnated by the Basic Constraints extension: a certificate owner is not granted CA power.

There is (currently) no such automatic enforcement of rules pertaining to Extended Key Usage. If a CA wants to enforce a no-SSL rule, then it must not issue certificates which can be used for SSL, and it must make sub-CA swear to comply to the same rule. Lack of such enforcement is a problem only if a sub-CA misbehaves, and the obtained certificate can be used as a SSL server certificate to perpetrate some odious crime before righteous revocation smites the offending sub-CA.

(Note that the Key Usage extension only covers a handful of generic use cases, such as "encryption" or "signature", and this is unrelated to Extended Key Usage. Moreover, the Key Usage extension is no more inherited along a certificate path than the Extended Key Usage extension.)


There is another point where rules can be engraved: in the clients. Clients trust root CA (that's what makes them "root CA"), but they can trust them for specific roles only. See for instance this screenshot from the certificate viewer in Firefox's preferences:

Firefox's preferences on a root CA

The list of "uses" is configurable and allows the client to restrict a given CA to some specific situations.

This mechanism:

  • is not backed by information written in the root CA certificate itself, but by metadata which must be maintained by some out-of-band mechanism;
  • is not standardized (every system has its own notion of "roles");
  • is specific to root CA (trust anchors) and cannot be attached to an intermediate CA;
  • is worth anything only insofar as the relevant applications mind the restrictions and enforce them.

Yet it works. If you want an S/MIME-only root CA, then distribute it and have it installed in clients with the tag "for S/MIME only". This is as good as a full-path automatic EKU extension (if such a thing existed).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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