<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I agree with the approach you defined in this pull request:<o:p></o:p></p><p class=MsoNormal><a href="https://github.com/cabforum/documents/issues/179">https://github.com/cabforum/documents/issues/179</a> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> Validation <validation-bounces@cabforum.org> <b>On Behalf Of </b>Ryan Sleevi via Validation<br><b>Sent:</b> Thursday, June 4, 2020 5:50 PM<br><b>To:</b> CA/Browser Forum Validation WG List <validation@cabforum.org><br><b>Subject:</b> Re: [cabf_validation] Sub-CAs and CP policy OIDs<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, May 12, 2020 at 4:09 PM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>I had an issue flagged by a CA and went and filed <a href="https://github.com/cabforum/documents/issues/179" target="_blank">https://github.com/cabforum/documents/issues/179</a> to try to capture the issue<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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 ( <a href="https://github.com/sleevi/cabforum-docs/pull/21">https://github.com/sleevi/cabforum-docs/pull/21</a> ) 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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div></div></div></body></html>