What Enhanced Key Usages are required for PKI infrastructure tasks? (OIDs for OSPF and CRL signing, etc)

Question

I'm building a constrained PKI that specifies EKUs for the the entire hierarchy and want to document the OIDs required for PKI tree maintenance tasks.

I understand that clients may not validate the entire EKU tree, just as some clients may not even check CRLs or OCSP URLs. My intent is to create a baseline of infrastructure that I can use to test interoperability and document how 3rd parties validate (or don't validate) certificates used by CAs.

Question

So assuming a client will validate a CRL, OSPF, or any other certificate that pertains to PKI infrastructure maintenance, what OIDs should I include at my Root EKU to enable a baseline of support + SMIME?

For example, a few OIDs that may relate to PKI infrastructure may include the signing of a sub CA (if such an OID exists), and also Qualified Subordination. However the issue I have is that all OIDs I can find fall under the Microsoft namespace of 1.3.6.1.4.1.311 or are simply listed on this web page. Since Microsoft didn't invent PKI, I don't want to create interoperability issues by only including their OIDs... I would want to include IBM's or Oracle's (Java's) implementation on CA validation.

Sample answer

The ideal answer would include a list of OIDs (in any format) and a description of what it's used for in as much detail as possible. The following is in "Capolicy.inf" format for Microsoft Certificate server, but all I care about is the information...

 ;OID = 1.3.6.1.4.1.311.20.2.1; Certificate Request Enrollment
 OID = 1.3.6.1.5.5.7.3.9;  OCSP Signing (Required for OCSP)
 ;OID = 1.3.6.1.5.5.7.48.1.5; OCSP signing (SHOWS AS UNKNOWN in some software)
 OID = 1.3.6.1.5.5.7.3.4 ; SMIME
 ; OID = 1.2.840.113549.1.9.15 ; On MSFT.com... Safari reports SMIME
 ; Should I include timestamping OIDs?

Also if there are certain OIDs that I shouldn't include then please include them as well. For example the following appear to be controversial and may escalate a certificates rights unnecessarily

;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING

Answer 1

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says:

In general, this extension will appear only in end entity certificates.

because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells things about possible usages for the public key in the certificate which features the extension, and only that public key. As such, your notion of "Root EKU" does not seem to make much sense to me.

As a general rule, lack of EKU does not prevent things from running, except in a few cases:

• The certificate for a delegated OCSP responder (i.e. when an OCSP response is not signed by the CA itself) MUST have an EKU with OID 1.3.6.1.5.5.7.3.9 (see RFC 2560, section 4.2.2.2).

• The certificate for a Time Stamp Authority MUST have an EKU with OID 1.3.6.1.5.6.7.3.8 (see RFC 3161, section 2.3, which also insist on the presence of only that OID in the EKU extension, exclusive of any other OID).

For other roles, the presence of the EKU extension is not mandatory, but shall be honoured if present. See for instance S/MIME Certificate Handling, section 4.4.4: if the extension is present at all, then the certificate should be considered as fit for S/MIME usage only if the 1.3.6.1.5.5.7.3.4 OID is present, or the special 2.5.29.37.0 OID is present (this is the "any extended key usage"). But lack of the extension is considered equivalent to an EKU with the "any extended key usage" OID.

There is no "extended key usage" for CA or CRL signing (for these, the basic "Key Usage" extension is considered sufficient).

Some systems can have extra system-specific requirements. For instance, for Smart Card Logon in an Active Directory context, certificates on the smart card and the certificates issued to the domain controller itself should both feature the Microsoft-specific 1.3.6.1.4.1.311.20.2.2. Microsoft are total fans of EKU; they even devised their own extension ("application policies", apparently not documented) which duplicates the information from the EKU extension.

Answer 2

There is no RFC about EKUs in CA certificates, so it is hard to give a reliable answer. A good, trustworhy looking, summary of status quo can be found here: https://www.gradenegger.eu/?p=697&lang=en , but please beware that that it comes from the Microsoft background, so the article claims EKU stands for "Enhanced Key Usage" instead of standardized "Extended Key Usage".

By that article you should consider adding:

• OID=1.3.6.1.5.5.7.3.9 "OCSP Signing" for issuing certificates for its OCSP responders.
• OID=1.3.6.1.4.1.311.20.2.1 "Certificate Request Agent" for cert automation by EOB/NDES.
• OID=1.3.6.1.4.1.311.21.5 "Private Key Archival" if you run a Microsoft CA.

I believe the "Certificate Request Agent" EKU requirement may not be a hard requirement, because the EOB/NDES agent should be able to work with a certificate issued by a different, more privileged, CA.

On the other hand, the "OCSP Signing" is a hard requirement for working OCSP, because rfc6960 requires a certificate of OCSP responder to be issued by the CA whose certificates it is supposed to validate.