[cabfpub] Increasing concurrent compliance compatibility

Peter Bowen pzb at amzn.com
Fri Jul 22 10:58:04 MST 2016


> On Jul 21, 2016, at 2:52 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Jul 21, 2016 at 2:24 PM, Peter Bowen <pzb at amzn.com> wrote:
> I propose that we amend the BRs to change the “trigger” for OV/IV to be the explicit inclusion of the appropriate CA/B Forum policy identifier rather than an implicit trigger based on attributes found in the Subject distinguished name.
> 
> This would allow CAs who are issuing certificates that need to comply with both the BRs and other certificate policies the ability to set the subject distinguished name as needed.  For example, some CAs may need to follow X.521 for the DN while others may need to use the country, state/province, and locality attributes to indicate legal jurisdiction rather than physical address and others may need to ensure that each legal or natural person has a distinct DN.
> 
> Concretely, if a certificate has one or both of:
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) baseline‐ requirements(2) organization‐validated(2)} (2.23.140.1.2.2)
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) baseline‐ requirements(2) individual‐validated(3)} (2.23.140.1.2.3)
> in its certificate policies extension, then the current BR requirements apply to the subject DN.
> 
> If neither are in the certificate policies extension, then the only Subject DN restriction would be on the commonName (CN) attribute.  All other attributes would be set according to the non-CABF policy for the certificate
> 
> I believe this would help resolve the issues Li-Chen has raised and I think it would help existing PKIs, such as the US Federal PKI, align their policies with the CABF BRs.
> 
> Anyone agree or disagree?
> 
> Thanks,
> Peter
> 
> Doesn't this create a rather large loophole for potential abuse/mistakes?
> 
> For example, I'm not aware of any browser that specifically recognizes the OV OID, but all display the organization information in some way, most commonly as some short-name in some form of UI.

Before proposing this change, I looked at several current web browsers and did not find them displaying the organization information for non-EV certificates outside of a UI buried numerous levels deep that shows the full contents of the certificate.  

If others want to test, https://www.sei.coop.br/ was the example site I used.  It uses an OV certificate which includes the organization-validated CABF policy OID in the policies extension.

> As proposed, if a CA didn't assert the OV OID, then it would seem reasonable that a CA might decide that no policies apply, and put "Google, Inc" in the O field.
> 
> Is that desirable? Is that right?
> 
> It's unclear whether CAs reasonably understand 7.1.2.4 (b), or whether that clearly prohibits that - or if it even should.
> 
> Similarly, what happens to 7.1.4.2.2 (i)? Do you see that being exempt?
> 
> Given Relying Party applications' longstanding and preexisting use of the fields (in particular, those noted in 7.1.4.2.2 a-h), I'm concerned with the introduction of semantics that would, in effect, change the meaning based on the policies asserted. If we were starting over from scratch, I would think it'd be an entirely reasonable suggestion, but given the preponderance of legacy systems in place, it seems slightly troublesome on principle to allow 'caveat CA' to rule here.

I’m very interested in any documented use of the subject DN attributes outside of commonName for non-EV server auth (SSL/TLS) certificates.  I have tried hard to find where they show in UI or in processing logic and have failed.

Thanks,
Peter



More information about the Public mailing list