1152017 - Please assign/require an OID for server certificates issued by a non-constrained subordinate CA

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Security: UI, defect)

Description

[Jeffrey Walton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150326190726

Steps to reproduce:

This is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1151348.

Currently, various public CA allows an organization to issue certificates for their Enterprise PKIs that chain back to a trusted root. Its a valuable service that accomplishes a number of goals and objectives.

However, the programs (and their associated policies and procedures) have gaps that can result in non-trivial risk for the end user. In particular, an organization that issues certificates effectively omits the independent third party auditor that validates the signing request (the RA).

Omitting the RA is not a concern *if* the subordinate CA is name constrained. The name constraint effectively serves as the independent auditor, and the system maintains its balance. 

Complete loss of the independent auditor and no complimentary security control is a major issue, however. Its a fundamental problem.

It appears a number of CAs are certifying organizational subordinate CAs and *not* placing name constraints on the subordinate CA. The situation effectively means an organization can mint certificates for all domains (and not just the web properties its owns and administers).

The unconstrained subordinate CA effectively creates a third class of certificate:

* Extended Validation (EV) - restores due diligence checking
    and restores CA profit levels.
* Domain Validation (DV) - minimal validation by third party,
    suffered race to the bottom
* Organization Validation (OV) - no request validation by a third
    party, organization just buys their way in, can mint
    certificates for any domain, "just trust us" security model

The non-constrained Organization Validated (OV) certificates are certificates issued by organizations using their subordinate CA without any type of constraint. These certificates are riskier because they have fewer assurances and confer less trust They are riskier because they lack independent third party validation and are not constrained.

Because non-constrained OV certificates have fewer assurances and confer less trust, they should not enjoy the same entitlements as a EV or even DV certificates. For example, the WebApp Sec working group is considering Secure Origins and ways to authorize access to power APIs. A non-constrained OV certificate probably should not have access to the power APIs because they lack any type of real assurances (other than the organization saying "trust us"). As another example for non-browser user agents, a certificate's class could be used in risk-based authorizations. Depending on the user's or organization's security posture, they may want to limit access by an origin secured with a non-constrained OV certificate; and require the site improve their standing by acquiring an EV certificate (i.e., subjecting the site to the more rigorous checks).

In both cases above, it clearly benefits the user to be able to identify the various classes of certificates. The user or organization can use the class to determine assurance levels associated and make sound decisions based on the rigorousness of the RA checks (or lack thereof).

Extended Validation (EV) certificates have an OID so users can identify them and make decisions based on them. That is, a user can place "more trust" in them and bestow more entitlements based on the EV status. The downside to EV certificates is there is no single OID for them, so it can be difficult to identify them (cf, https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification).

While EV certificates have a way of identifying themselves, Organization Validated certificates do not.

Please assign an OID for non-constrained Organization Validated certificates so we can identify them. Please require all subordinate CAs to include the same OID so they are easy to identify when we encounter them in the wild. Please also create policy for them.

Note that I'm not asking for outside consensus. This is something that the Mozilla can initiate to protect its users. If others see values in the practice of protecting users, then it can be codified at other places.


Actual results:

No way to easily differentiate non-constrained Organizational Validated (OV) certificates from other classes of certificates, like DV and EV. (Well, you can identify EV but its not easy).


Expected results:

We should be able to easily identify non-constrained Organizational Validated (OV) certificates. I would expect the mechanism to be similar to EV certificates (but unlike EV certificates, we should be able to easily identify them through a single OID).

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

This first requires a larger discussion in https://groups.google.com/forum/#!forum/mozilla.dev.security.policy and/or the ca/browser forum.

Comment 2

[Jeffrey Walton]

The web security folks crack me up... The problem and the risk is present; a discussion on a forum has nothing to do with it.