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.

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
share|improve this question
add comment

1 Answer

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.

share|improve this answer
    
Regarding the inheritance and root eku, suppose I wanted to have a sub ca (or entire PKI tree for that matter) only issue smime... Does that that mean its impossible to constrain a ca to only issue certs of a given type, or is there a way to do so outside of the eku? ( given that the clients should reject a cert issued outside of a properly constrained hiarchy) –  makerofthings7 Jun 18 at 3:27
add comment

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.