This does not sound like a security bug, but rather a feature request for AutoSelectCertificateForUrls. Derestricting the view and cc-ing davidben@ and mattm@ for triage.

Redirecting to Enterprise

We currently only support matching by Issuer CommonName[1].

I do think it makes sesne to add more matching criteria.
Ideally, we'd be on-par with ONC[2], which supports
Issuer CommonName
Issuer Locality
Issuer Organization
Issuer OrganizationalUnit

Subject CommonName
Subject Locality
Subject Organization
Subject OrganizationalUnit

To adhere to the existing style of the AutoSelectCertificateForUrls policy, we could call these:
top-level: ISSUER and SUBJECT
second level: CN, L, O, OU. 

[1] https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?type=cs&sq=package:chromium&g=0&l=703
[2] https://chromium.googlesource.com/chromium/src/+/master/components/onc/docs/onc_spec.md#CertificatePattern-type

If possible we should reuse the matching code - however it currently is in //chromeos/network, while this matching is in //chrome/browser, so we'd have to move that code to a place usable from both.
Maybe //component/certificate_principal_matcher ? Discussing if that is overkill.

Targeting M-74 at the moment.

I've received pushback in the past (regarding https://chromium.googlesource.com/chromium/src/+/HEAD/components/README ), as these aren't about iOS, Android, or "embedders" of Chrome. That said, perhaps the definition has changed regarding ChromeOS, as evidenced by ONC, in which case, //components/ would be the right place. To pre-emptively head it off, I don't think //net is a good place :)

Would this common code include stuff like  CertificatePattern::ReadFromONCDictionary, which seems to pull in, e.g., onc::client_cert::kIssuer?

I wonder if it should just be in components/onc then, considering these patterns are defined in ONC to begin with. A little bit of silliness with having that pattern format be used outside CrOS too, but having a common certificate pattern throughout seems sensible.

Yeah I thought about having the shared code only define
- a CertificatePattern::PrincipalPattern class which would take 4 strings in its ctor (for CN,L,O,OU)
- a CertificatePattern class which would have a ctor that takes two PrinipalPatterns (for subject and issuer).
(we could add things like SANs later if we want).
  CertificatePattern would have a virtual bool Match(const X509Certificate&) method.

The AutoSelectCertificateForUrls policy code would create these from the JSON there.
The ONC code would also depend on it and would subclass CertificatePattern -> OncCertificatePattern (which holds stuff such as enrollment_uri) and would contain parsing logic there I guess.

So yeah, it is probably not enough code to justify a component w/ OWNERS,README,BUILD :-) OTOH I don't think there's any other sensible place to put this. We may just end up duplicating the code.

New idea: I'll try to move the common code to //components/policy as the patterns are fundamentally a policy feature and that code can be used from both //chrome/browser and //chromeos. Yay!

WIP: https://chromium-review.googlesource.com/c/chromium/src/+/1405011