<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=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:.5in;
mso-add-space:auto;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
mso-add-space:auto;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
mso-add-space:auto;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:.5in;
mso-add-space:auto;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
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:1937593140;
mso-list-type:hybrid;
mso-list-template-ids:1069315430 -1812400686 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:2022;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
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="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hello,<o:p></o:p></p><p class=MsoNormal>Andrea forwarded the minutes she took for our previous call (thanks Andrea!). Please review and we’ll approve either tomorrow or the meeting after (depending on how many have a chance to review).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-------------<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>Validation Subcommittee – Minutes of Thursday, June 16, 2022</b><o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Attendance</b>: Aaron Poulsen (Amazon Trust Services), Amanda Mendieta (Apple), Andrea Holland (SecureTrust), Aneta Wojtczak (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell (DigCert), Dustin Hollenback (Microsoft), Emily Stark (Google Chrome), Hubert Chao (Google Chrome), Inigo Barreria (Sectigo), Jamie Mackey (GSA FPKIMA), Joanna Fox (TrustCor), Joe Ramm (OATI), Johnny Reading (GoDaddy), Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Paul van Brouwershaven (Entrust), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera), Tyler Myers (GoDaddy),<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Antitrust Statement:</b> Read by Corey Bonnell<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Previous Minutes:</b> Minutes have not gone out yet.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b><u>Profiles Ballot</u></b><o:p></o:p></p><p class=MsoNormal>Corey - Today we will be continuing the presentation where we left off from the face to face. We went through an overview of the some of the must not level requirement changes on the certificate profiles ballot. Resuming today with the should not and not recommended changes and the impact there. <o:p></o:p></p><p class=MsoNormal>Presentation link: <a href="http://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf">http://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf</a><o:p></o:p></p><p class=MsoNormal>Should (Not) level changes – Subject<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>streetAddress and postalCode is now a not recommend.<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey - There will be certificates impacted although CAs have been phasing this out already. Should not and not recommend are identical as far as RFC 2119 standpoint.<o:p></o:p></li></ul><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Any attribute not explicitly listed in the ordering table should not be included<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey- Unintended side effect of current language is it does not include any of the attributes that are required for EV certificates.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Aneta – We can explicitly add EV required attributes.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Andrea – Or we can reference the EV guidelines instead.<o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – We might need to add ordering of EV attributes since EV guidelines does not explicitly list an order, but there is a wide variation across CAs on the ordering of the attributes so if we mandate an order, we will need an effective date.<o:p></o:p></li></ul></ul><p class=MsoNormal>Should (not) level changes – KeyUsage<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>RSA: digitalSignature and keyEncipherment together is now a should not<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – This is a widespread practice and there will be a wide impact to certificates. There is some good language in the ballot explaining the rationale behind this decision. TLS 1.3 only requires a digital signature bit be asserted, where some of the older protocols require the key encipherment be asserted.<o:p></o:p></li></ul></ul><p class=MsoNormal>Should (not) level changes – certPolicies<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>The first policy OID should be a reserved CABF policy OID<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey - This has benefits when doing policy chaining which is only relevant to EV UI display<o:p></o:p></li></ul></ul><p class=MsoNormal>Should (not) level changes – Authority Key Identifier<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Should be included in Root Certificates<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – It is very common for CAs to not include this which is likely the result of RFC 5280 guidance.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Ben – What was the rationale for this considering it is against the RFC.<o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – The rationale behind this is to assist user agents that do not follow the RFC to help them more efficiently perform path building. Although it is not explicitly necessary for the user agents.<o:p></o:p></li></ul></ul><p class=MsoNormal>Should (not) level changes – Name Constraints<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Should not contain permittedSubtrees or excludedSubtress that are not of type dirName, iPAddress, or dNSName<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey - Somewhat conflicts with the current Mozilla root policy, ICA’s if they are to be considered technically constraints they need to have either EKU constraints or name constraints for all four of dirName, iPAddress, dNSName, and the other name type for server names. Although this might not result in any concrete issues since this is should not level change.<o:p></o:p></li></ul></ul><p class=MsoNormal>Should (not) level changes – Other Extensions<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Should not contain extensions that are not explicitly listed in the Extensions table<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey - Examples of notable ones in use that are not included: MSFT Template Name (etc.), QCStatements, TLSFeature (OCSP Must-Staple).<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Paul – What is the reasoning behind not including QCStatements or OCSP Must-Staple.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – Would need to review the discussions from late last summer, but idea that anything that is not fully described in the profiles ballot should not be included.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Inigo – The QCStatements have not been discussed between the browsers and the EU commission since they are still discussing several aspects around QWACs. There is an ETSI standard profile for QWACs which includes QCStatements. This creates a contradiction since a CA has to follow the corresponding CABF standards to be certified but in order to issue QWACs you have to follow the ETSI standards. Especially if the should not becomes a shall not in the future. The EU commission and browsers are still discussing validating the certificates with the EUTL which also requires you to follow the ETSI standards. <o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – It could be construed as contradictory. The information in this presentation is based on the current draft ballot, so we can revisit some of these decisions in light of new information.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Emily – has this evolved from shall not to a should not or has this always been a should not?<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – I would have to revisit this language, but it was never a shall not or must not. This may have fluctuated between you may include other extension levels.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Ben – For Mozilla on the Must-Staple, I am not sure what the rational is maybe server administrators would want to put in their certificates, but it seems okay to have a should not because they can add it if they need it.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Dustin – What is the impact for certificates? Should we investigate? This one might be more impactful, so it would be good to known.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – I was unable to grab the impact information due to time, but you can find out the specific extension OIDs and you can do a search on censys with unknown extension id or for QCStatements. I believe delegated credentials have specific certificate extensions in them and if they are not explicitly enumerated the net result is a should not violation if included. It would be good to get an impact analysis on this change.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Clint – The intent was to expand the list to explicitly listed extensions in v2. So, until we have a well-defined referenced document or set of validation requirements it makes sense for them to be a should not. The idea is to have something that relying parties can rely on to demonstrate what CA’s are doing. CAs can work on getting these less defined extensions better defined with standards or reference document to be included on the explicit list. The extension could be added in this ballot, if it is ready, or v2 or a standalone ballot, if necessary. <o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Dustin – If someone has an extension that they want added could it be added now. If it is a really impactful extension that might justify adding it to the may now as long as there is a reference, but the onus is on the impacted CAs.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – It is difficult to find all the use cases. Having the CAs that are potentially impacted do the digging and research makes sense.<o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Martijn – I did a rough look up (it is rough because I didn’t check for duplicate precerts or leaf certificates nor check against if the root was trusted) QCStatements has 16k active certificates and TLSFeature has 1.3 million active certificates.<o:p></o:p></li></ul></ul><p class=MsoNormal>V2 – Who defines OID<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Corey – A lot of RFCs will have their own OID and there might be similar arrangements on a private level or other formalized standards documents. It would be valuable to know when use of an OID has been granted so CAs are not adding OIDs that the OID arch owner might not approve of.<o:p></o:p></li></ul><p class=MsoNormal>V2 – Certificate Policies<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>V1 allows cPSUri in all non-Root certificate types. The proposal to disallow all qualifiers for Sub CA certificates with anyPolicy<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – This is essentially codifying an RFC 5280 should not level requirement, if the anyPolicy OID is expressed then no qualifiers should be included in the certPolicies extension.<o:p></o:p></li></ul><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>V1 allows for Certificate policies extension in OCSP responders until the sunset date<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – There was good discussion on this item last week. Ryan Dickson is going to follow-up on the way policy constraints are handled in chrome.<o:p></o:p></li></ul></ul><p class=MsoNormal>V2- Naming<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>V1 makes OrganizationName in IV certificates a not recommended. V2 proposal is to make it a must not.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Defining naming requirements for OCSP delegated responder certificates.<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey- There was some discussion on github on whether or not names can be reused across generations for ocsp delegated responders and this would be valuable to clarify on v2<o:p></o:p></li></ul><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Defining requirements for dnQualifier attribute to enable sunset of CN. <o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – This was proposed years ago by Peter Bowan would allow for deprecation of common name in certs but still allow for non empty subject dn. There were some concerns at the time that if you didn’t include the common name the subject dn would be empty and would cause interoperability issues with some clients. The idea is to instert a dn qualifier attribute so the Subject dn is no longer empty.<o:p></o:p></li></ul></ul><p class=MsoNormal>V2- Other items<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Define requirements for other extensions. <o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Prohibit all non-TLS issuance<o:p></o:p></li><ul style='margin-top:0in' type=circle><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level2 lfo1'>Corey – This is for a root that is audited by TLS BRs essentially moving to single use hierarchy. If there are additional items that we want to tackle, we can add them as well.<o:p></o:p></li></ul></ul><p class=MsoNormal>Other Comments<o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Ben – Question on the Subject dn are we going to change our course on that item.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Corey – My personal opinion this is a large normative change for something that was previously allowed. There is an international research community that uses these certificates. Their use case should be accommodated at least in the short-term. Their PKI operations would be drastically disrupted.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Clint – We should be able to add language to define how they are validated against 3224 that covers the concern. The concern is there are values that are potentially misleading since we don’t know how they are validated.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Ben – I see your point but I don’t know how they go about validating it.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Clint – Is that something that CAs can provide some insight the subject dn how are they being validated. So we can understand how disruptive it would be. Mostly Sectigo and DigiCert that have impacted customers. Can we get that information from you?<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Corey – That is something that we can dig into to come up with more specific validation requirements. The main concern is that the ballot language prohibits the inclusion of the same attribute type multiple times that would need to be accommodated.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Clint – That can be accommodated as long as we have some base requirements for how those values are validated. It would be helpful to see what the current processes are so we can put in validation requirements, maybe they are being validated by 3224 already. If it is truly disruptive to put in validation requirements, we will have to think of a different path because we don’t want to disrupt an impactful community unnecessarily. We do want to have some baseline requirements of how those certificates are being validated.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Corey – That is a good approach, the idea that we defined the validation requirements in the BRs after we have an evaluation of current practice. Then we would have an explicit carve out to allow for multiple domain component attributes to appear in a single dn.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Dustin – Thank you Corey for making the case impact reports.<o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo1'>Corey – I hope that in the future we can do similar analysis like this to concretely view the impact of potential changes. <o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>