Determining Certificate Applicability with Standard CABF CP OIDs

Determine Applicability of Certificates by using standard CABF CP OIDs Wen-Cheng Wang, Ph.D. Chunghwa Telecom Co., Ltd.

Determine applicability of certificates Q: When a certificate-using software (such as a browser) encounter a SSL certificate or a code-signing certificate that is chained up to a trusted Root CA, how does it determine whether the certificate is issued by a Subordinate CA that conforms the applicable CA/Browser Forum guidelines? A: Currently, there is no systematic and automatic way to check this applicability. 2

Mis-issuance by Unconstrained CA WebTrust for CA audited RootCA 1. SubCA3 is not WebTrust SSLBR Audited or WebTrust EVCS audited 2. SubCA3 could mis-issuse SSL certificates or EV Code Signing certificates unless all SubCAs are Technically Constrained SubCA1 WebTrust SSLBR audited SubCA2 WebTrust EVCS audited SubCA3 EV Code Signing Cert EV Code Signing Cert OV SSL Cert OV SSL Cert 3

Sub CA Constrained by EKU WebTrust for CA audited RootCA WebTrust SSLBR audited WebTrust EVCS audited SubCA1 EKU = {id-kp-serverAuth} SubCA2 EKU = {id-kp-codeSigning} SubCA3 EKU = {some other EKU} X X The EKU chaining will be failed EV Code Signing Cert EKU = {id-kp-codeSigning} EV Code Signing Cert EKU = {id-kp-codeSigning} OV SSL Cert OV SSL Cert EKU = {id-kp-serverAuth} EKU = {id-kp-serverAuth} 4

Using EKU in Sub CA certificate is controversial Extended Key Usage (EKU) extension The section 4.2.1.12 of RFC 5280 says In general, this extension will appear only in end entity certificates. Both ITU-T X.509 and RFC 5280 say nothing about the semantics if this extension appeared in CA certificates. EKU Chaining (a.k.a. EKU nesting) The is no such thing in the standard certification path validation procedure define in both ITU-T X.509 and RFC 5280. 5

The Solution: Using CP OID to determine applicability The X.509 standard and RFC 3647 define a Certificate Policy (CP) as A named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate the applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. A CP is represented in a certificate by a unique number called an "Object Identifier" (OID). When a CA places multiple CPs within a certificate's Certificate Policies extension, the CA is asserting that the certificate is appropriate for use in accordance with any of the listed CPs. 6

CA/Browser Forum CP OID EV SSL CP OID: 2.23.140.1.1 EV Code Signing CP OID: 2.23.140.1.3 DV SSL CP OID: 2.23.140.1.2.1 OV SSL CP OID: 2.23.140.1.2.2 IV SSL CP OID: 2.23.140.1.2.3 Each CP OID indicate the applicability of different type of certificate 7

From the perspective of audit WebTrust Audit Applicability SSL Baseline + Network Required CS Publicly Trusted N/A RKGC CA EV SSL EV CS Required Required N/A N/A Publicly-Trusted PKI - SSL Required Required Required Required N/A N/A Publicly-Trusted PKI - EV SSL Required Required Required Required N/A N/A Not Required Not Required N/A Required Required Publicly-Trusted PKI - CS Publicly-Trusted PKI - EV CS Publicly-Trusted PKI - All other uses Required Required Required N/A Not Required N/A N/A 8

From the perspective of audit CABF Network Security Requirements WebTrust for CA audited Private CP (CP OID = a.b.c.d) CABF BR RootCA DV SSL CP OID: 2.23.140.1.2.1 OV SSL CP OID: 2.23.140.1.2.2 IV SSL CP OID: 2.23.140.1.2.3 in compliance to WebTrust SSLBR audited CPS of SubCA1 SubCA1 CP OIDs: {a.b.c.d, OV SSL CP OID} CABF BR + CABF Network and Certificate System Security Requirements define a set of rules (i.e. effectively a CP) for the applicability of publicly-trusted DV, OV, or IV SSL certificates SubCA1 Cert CP OIDs: {a.b.c.d, OV SSL CP OID} OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} CP OID Chaining 9

CP OID Chaining CP OID Chaining is well-defined in the certification path processing procedure of the X.509 standard and RFC 5280 user-initial-policy-set: comprising one or more certificate policy identifiers, indicating that any one of these policies would be acceptable to the relying party for the purposes of certification path processing initial-explicit-policy = true: indicates an acceptable policy identifier needs to explicitly appear in the certificate policies extension field of all public-key certificates in the path Processing intermediate certificates: each CP OID that appears in an intermediate certificates must also appear in the upper- level intermediate certificate or in the user-initial-policy-set Each CP OID that appears in the end-entity certificate must also appear in the intermediate certificates 10

Example of CP OID Chaining initial-explicit-policy = true user-initial-policy-set = {OV SSL CP OID} RooCA Cert CP OID Chaining SubCA1 Cert CP OIDs: {a.b.c.d, OV SSL CP OID} CP OID Chaining OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} 11

Example of CP OID Chaining WebTrust for CA audited Private CP (CP OID = a.b.c.d) initial-explicit-policy = true user-initial-policy-set = {OV SSL CP OID, EV Code Signing CP OID} RootCA WebTrust SSLBR audited WebTrust EVCS audited SubCA1 CP OIDs: {a.b.c.d, OV SSL CP OID} SubCA2 CP OIDs: {a.b.c.d, SubCA3 CP OIDs: {a.b.c.d} EV Code Signing CP OID} EV Code Signing Cert CP OIDs: {a.b.c.d, OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} EV Code Signing CP OID} 12

Using CP OID Chaining to detect mis-issuance WebTrust for CA audited Private CP (CP OID = a.b.c.d) initial-explicit-policy = true user-initial-policy-set = {OV SSL CP OID, EV Code Signing CP OID} RootCA WebTrust SSLBR audited WebTrust EVCS audited SubCA1 CP OIDs: {a.b.c.d, OV SSL CP OID} SubCA2 CP OIDs: {a.b.c.d, SubCA3 CP OIDs: {a.b.c.d} EV Code Signing CP OID} X X EV Code Signing Cert CP OIDs: {a.b.c.d, EV Code Signing Cert CP OIDs: {a.b.c.d, OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} EV Code Signing CP OID} EV Code Signing CP OID} 13

Using CP OID Chaining to detect mis-issuance Private CP (CP OID = a.b.c.d) initial-explicit-policy = true user-initial-policy-set = { DV SSL CP OID OV SSL CP OID IV SSL CP OID} RooCA Cert X SubCA2 Cert CP OIDs: {a.b.c.d, CP OID Chaining EV Code Signing CP OID} CP OID Chaining EV Code Signing Cert CP OIDs: {a.b.c.d, EV Code Signing CP OID} 14

What about name constraints initial-explicit-policy = true user-initial-policy-set = {OV SSL CP OID} RooCA Cert No problem! You can specify name constraints. CP OID Chaining SubCA1 Cert CP OIDs: {a.b.c.d, OV SSL CP OID} Name Constraints: permittedTree = example.com CP OID Chaining OV SSL Cert CP OIDs: {a.b.c.d, OV SSL CP OID} 15

Adoption of CABF CP OIDs As of 5 Oct 2017 Company Buypass Chunghwa Telecom Comodo Digicert Digicert Digicert D-Trust D-Trust Entrust Globalsign Globalsign Globalsign GoDaddy GoDaddy GoDaddy Identrust Identrust Izenpe Logius QuoVadis QuoVadis Starfield Starfield Starfield Startcom SwissSign Symantec Trend Trustis Trustwave TurkTrust TurkTrust WoSign WoSign CABF Compliance OIDs BR OID BR OID BR OID 2.16.840.1.114412.1.2 2.16.840.1.114412.1.1 2.16.840.1.114412.2.1 1.3.6.1.4.1.4788.2.200.1 1.3.6.1.4.1.4788.2.202.1 BR OID 1.3.6.1.4.1.4146.1.10.10 1.3.6.1.4.1.4146.1.20 1.3.6.1.4.1.4146.1.1 2.16.840.1.114413.1.7.23.1 2.16.840.1.114413.1.7.23.2 2.16.840.1.114413.1.7.23.3 2.16.840.1.113839.0.6.3 2.16.840.1.101.3.2.1.1. 5 1.3.6.1.4.1.14777.1.2.1 2.16.528.1.1003.1.2.5.6 1.3.6.1.4.1.8024.0.2.100.1.1 1.3.6.1.4.1.8024.0.2.100.1.2 2.16.840.1.114414.1.7.23.1 2.16.840.1.114414.1.7.23.2 2.16.840.1.114414.1.7.23.3 BR OID 2.16.756.1.89.1.2.1.1 2.16.840.1.113733.1.7.54 1.3.6.1.4.1.34697.1.1 1.3.6.1.4.1.5237.1.1.3 1.3.6.1.4.1.30360.3.3.3.3.4.4.3.0 2.16.792.3.0.3.1.1.2 2.16.792.3.0.3.1.1.5 1.3.6.1.4.1.36305.2 BR OID Comments OV OV,DV DV OV EV OV EV DV OV EV DV OV EV Commercial Will also include CABF OIDS 2.23.140.1.2.1 Public Sector Will also include CABF OIDS 2.23.140.1.2.1 Will also use CABF OID OV only OV EV DV OV EV EV Verisign, Thawte, GeoTrust OV EV EV OV, DV 16

What should we do? Enforce to adopt CABF CP OIDs Set a sunrise date Effective DD MM YYYY, CAs MUST use the following CP OIDs in the subordinate CA certificates and the subscriber certificates. Note that Microsoft Root Certificate Program already mandate the use of CABF CP OIDs 4.15 CAs must use the following OIDs in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV 2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4. For Browsers All of the Root CA certificates in the trust list must associate with one or more applicable CABF CP OIDs 17

Conclusions The Advantages of determining the applicability of certificates by using standard CABF CP OIDs instead of EKUs It can provide a uniform, systematic, and automatic way to determine the applicability of different types of certificates. It is fully compliant to the certification path processing procedure defined in the X.509 standard and RFC 5280. Let s do the right thing in a way that we do it right Do the right thing: we must always check the applicability of certificates Do it right: By enforcing standard CABF CP OIDs, we can systematically check applicability of certificates 18