<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: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;}
p.gmail-m-2840431725223393811msolistparagraph, li.gmail-m-2840431725223393811msolistparagraph, div.gmail-m-2840431725223393811msolistparagraph
{mso-style-name:gmail-m_-2840431725223393811msolistparagraph;
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;}
p.gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph, li.gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph, div.gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph
{mso-style-name:gmail-m_-2840431725223393811gmail-m-5979062173272696968msolistparagraph;
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.EmailStyle20
{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;}
/* List Definitions */
@list l0
{mso-list-id:54203581;
mso-list-template-ids:2039790192;}
@list l1
{mso-list-id:338238393;
mso-list-template-ids:-1785706610;}
@list l2
{mso-list-id:1398091421;
mso-list-template-ids:-131849618;}
@list l3
{mso-list-id:1832985297;
mso-list-template-ids:-940515178;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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>Ryan,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If the current spec lists just the 3 fields, and the end game is just these 3 fields, then is it <i>necessary</i> to formally adopt an intermediate set of fields to allow other attributes until we prohibit them? <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Perhaps we just update the section 7.1.4.3.1 to say: As of (some date in 2020), No other attributes are permitted.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Maybe there are specific short term needs, and if so, then we should only permit those very few attributes for this transitional period. Let’s not make this a bigger job than we need.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Personally I see value in Locality and state/Prov especially when it comes to Vanity CAs, so I’m looking forward to seeing why these are harmful to the community (again).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Wednesday, June 10, 2020 10:19 AM<br><b>To:</b> Doug Beattie <doug.beattie@globalsign.com><br><b>Cc:</b> Tim Hollebeek (tim.hollebeek@digicert.com) <tim.hollebeek@digicert.com>; CA/Browser Forum Validation SC List <validation@cabforum.org><br><b>Subject:</b> Re: Subject DN attributes in ICA certificates<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Hi Doug,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If you'd like to propose a ballot, I think we'd be happy to draft. I think during the lengthy discussion of this issue, in which I tried to engage CAs, we highlighted several issues:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1) These fields are both unnecessary and harmful to the broader web. We understand not all CAs are familiar with the issues here, and so we know there is still discussion to be had, but any permitting of these fields needs to be time limited<o:p></o:p></p></div><div><p class=MsoNormal>2) Similarly, we need to make sure that these intermediates are not part of the ecosystem long term, and so a limit on how long they can issue certificates that chain to them (e.g. similar to the discussion about subject/issuer name comparison)<o:p></o:p></p></div><div><p class=MsoNormal>3) The list of fields is <a href="https://github.com/cabforum/documents/issues/154">https://github.com/cabforum/documents/issues/154</a> and so we still need to define validation requirements for those<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Jun 10, 2020 at 10:08 AM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.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><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Then it seems impossible to proceed with an updated profile ballot without clarification ballots.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As a first step, I’d like to propose a ballot where we specify optional and required fields in Subordinate CA certificates and their associated validation rules. Specifically, updates to section 7.1.4.3.1:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>a) CN: No change<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>b) O: no change except to add that this field is validated in accordance with 7.1.4.2.2 b.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>c) C: No change<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Add:<o:p></o:p></p><ul type=disc><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>organizationalUnitName – optional, if present validated same as 7.1.4.2.2 i.<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>stateOrProvinceName - optional, if present validated same as 7.1.4.2.2 f.<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>localityName - optional, if present validated same as 7.1.4.2.2 e.<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>streetAddress – optional, if present validated same as 7.1.4.2.2 d.<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>postalCode – optional, if present validated same as 7.1.4.2.2 g.<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>Possibly others as determined during discussion phase, like organizationalIdentifier<o:p></o:p></li><li class=gmail-m-2840431725223393811msolistparagraph style='mso-list:l3 level1 lfo1'>All others: Prohibited<o:p></o:p></li></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This permits a mix/match of the added optional fields up to the CAs policies and procedures, and if present, then they must be validated in accordance with the same rules as subscriber certificates.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Is this going to fly?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> <br><b>Sent:</b> Wednesday, June 10, 2020 9:35 AM<br><b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>><br><b>Cc:</b> Tim Hollebeek (<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>) <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> Re: Subject DN attributes in ICA certificates<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Wed, Jun 10, 2020 at 8:38 AM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ryan, Tim and group,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I was looking at the CA Certificate Profile page yesterday and had a couple of questions.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><ol start=1 type=1><li class=gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph style='mso-list:l1 level1 lfo2'>For ICAs, the BR lists 3 subject DN attributes and remains silent on the remaining. We see lots of CAs including other attributes (State/Prov, Locality, etc.) and it’s not clear if this is a violation of the BRs or not (default deny discussion…). Even after a long thread [1], we didn’t come to a consensus. I don’t want to open that can of worms here, but the question is, as we update this section with the intent of not making material changes, what DN fields do we say are permitted? Currently the page says Optional in the optional/required column but says prohibited further to the right (along with a reference to the DN tab for validation rules which implies it’s permitted). Does this update intend to clarify what’s permitted and the associated validation rules? Do we need a ballot prior to this Profile ballot to define permitted attributes and to specify the validation rules?<o:p></o:p></li></ol></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Yes, we need a ballot to resolve this.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><ol start=1 type=1><li class=gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph style='mso-list:l0 level1 lfo3'> <o:p></o:p></li><li class=gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph style='mso-list:l0 level1 lfo3'>Related to this, the definition of Org is currently: “This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2”. I could not find a definition of “Subject CA’s Name” to know what exactly that means. A number of CAs, GlobalSign included, issue “Vanity” CAs. Those are CA certificates in the name of a 3<sup>rd</sup> party and run by the CA identified in the Certificate Policy CPS link. As we clarify the validation rules for fields in CA certificates, we should be clear on what we mean by “Subject CA’s name” and how these attributes are validated. This was discussed in 2017 as part of Ballot 199. Gerv said it was permitted [2], and Ben said [3] this was part of the Policy WG discussion about “CA” and “CA Operator”, which I don’t think was ever reflected in the BRs.<o:p></o:p></li></ol></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>That seems to be confusing CN with O name. You seem to be discussing a different field than Gerv, have I confused anything?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><ol start=1 type=1><li class=gmail-m-2840431725223393811gmail-m-5979062173272696968msolistparagraph style='mso-list:l2 level1 lfo4'> <o:p></o:p></li></ol><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We should come to conclusion on both of these as part of clarifying the certificate profiles and attribute validation rules. Do we need a ballot on these before we can finalize the certificate profiles?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ryan – I believe you created a list of all subject Attributes you found in CAs at some point. Is that the starting point we wanted to use as the “whitelist” of attributes as we clarify what is permitted?<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Yes, and I circulated it multiple times for feedback. It was the process of preparing a Ballot that revealed the systemic issues that we're now discussing with profiles, in order to resolve matters like how you highlight. I just didn't expect we'd be spending so long on profiles.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[1] <a href="https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001154.html" target="_blank">https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001154.html</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[2] <a href="https://lists.cabforum.org/pipermail/public/2017-May/010928.html" target="_blank">https://lists.cabforum.org/pipermail/public/2017-May/010928.html</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[3] <a href="https://lists.cabforum.org/pipermail/public/2017-May/010936.html" target="_blank">https://lists.cabforum.org/pipermail/public/2017-May/010936.html</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Doug<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> <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 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> Re: [cabf_validation] Sub-CAs and CP policy OIDs<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, May 12, 2020 at 4:09 PM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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" target="_blank">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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></div></blockquote></div></div></div></div></blockquote></div></div></div></body></html>