[cabf_validation] Sub-CAs and CP policy OIDs

[Doug Beattie]

I agree with the approach you defined in this pull request:

https://github.com/cabforum/documents/issues/179



Doug



From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi 
via Validation
Sent: Thursday, June 4, 2020 5:50 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Sub-CAs and CP policy OIDs







On Tue, May 12, 2020 at 4:09 PM Ryan Sleevi <sleevi at google.com 
<mailto:sleevi at google.com> > wrote:

I had an issue flagged by a CA and went and filed 
https://github.com/cabforum/documents/issues/179 to try to capture the issue



The TL:DR: is how to handle a sub-CA that wishes to use the CABF OIDs within 
their end-entity certificates, but is not Affiliated with the Root.



Bumping this, and hoping to get some feedback from other root programs as to 
whether or not they see it as an issue with the BRs, and whether the attempted 
solution ( https://github.com/sleevi/cabforum-docs/pull/21 ) is aligning in 
the right direction. As it is, it raises questions about whether some Sub-CAs 
are in compliance, and creates challenges for issuing new Sub-CAs, so I want 
to make sure we're moving in the right direction and giving CAs the clarity 
they need from Root Programs.



Separate from that more immediate issue, I'm also starting to wonder whether, 
longer-term, we should restructure how we handle these policy OIDs, to make it 
easier for Relying Party software to use certificatePolicies for verification, 
rather than the (implemented by Google/Mozilla/Microsoft) EKU chaining 
behaviour. This would likely help resolve some of the issues around separate 
trust frameworks, by more clearly asserting the trust framework (or 
frameworks) a certificate belongs to. That's not something we need to 
immediately tackle, as we can still smoothly transition later, but the way our 
current requirements are structured, which this PR tries to preserve, prevents 
that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200611/808ed563/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5688 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200611/808ed563/attachment.p7s>