<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",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;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Georgia",serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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 bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Our systems are focused on enterprises, who have the ability to come back to a portal whenever they like and get new certs for organizations and domains that have been validated.
This continues for as long as the BRs allow re-use of proper validation data – at that point, all domains will be revalidated using the updated validation methods.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We never know when an enterprise customer will want a new cert for a validated domain (it could be Saturday night), and they will be very surprised, and very unhappy, if they
request a new cert and are denied. They will also be unhappy having to go through a validation process again while they are waiting for their cert, when there was nothing wrong with the prior validation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">As I said on the call yesterday, we can’t run a query on our vetting system and ask “Which of the many tens of thousands of domains (yes, it’s that many) validated in our system
were validated using Method X?”. The only way to know that is to manually examine ALL of the tens of thousands of vetting files for those domain, one by one, to record which were validated using Method X. That’s step one, and it would take hundreds of vetter-hours
to complete.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Step 2 would then be to immediately revalidate all those domains that were previously validated using Method X – let’s say Method 6 (</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Agreed
Upon Change to Website). I have received a SWAG that as many as 10,000 domains would have to be revalidated using new Method 6. This is a very manual, time-consuming process that requires emails and phone calls to each customer, then waiting/checking to
see if the customer has pasted the required data on the correct path for EACH domain the customer previously vetted using old Method 6. It could take hours or days for enterprise customers to complete each one. Let’s assume it takes 30 minutes of vetter
time to revet each domain using new Method 6 – for 10,000 domains that’s 5,000 vetter hours, or (using 7.5 hour days) 667 vetter days to complete 10,000 revettings. To get it done in 30 days, that would require 22 additional vetters to work on nothing but
Method 6 revalidation to get the job done (our existing vetting team is already very busy on regularly scheduled vettings and revettings). And again, our enterprise customers have an expectation they can get certs for any of these domains at any time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Normally CAs give their customers advance notice when revetting is required (e.g., starting at 90 days, then at 60 days, then at 30 days), and our vetting team works hard over
that period to make sure every customer gets revetted in time so there is no break in the customer’s ability to order new certs at any moment. To suddenly add a requirement that past domain vetting data still in its permitted re-use period can no longer be
used and all those domains (after we find them in Step 1 above, which will also take hundreds of hours of time first) must be revetted using new Method 6 makes no sense UNLESS someone can show an actual, confirmed security problem that requires immediate action.
So far, that hasn’t happened. And as I said before, we have NEVER received a report of complaint from anyone that a domain we vetted using old Method 6 was not correct or the resulting cert was mis-issued.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We should simply apply the new vetting rules to new domains, and continue to allow re-use of prior domain vetting information that complied with the permitted vetting methods
at the time they were validated. I worked on Ballot 169 for at least 18 months (I was actually the person who pushed the Validation Working Group to complete the ballot), and there was never an intent that the new validation methods would require re-vetting
of existing domain validation data.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I hope this information is helpful.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Jos Purvis (jopurvis) [mailto:jopurvis@cisco.com]
<br>
<b>Sent:</b> Friday, April 28, 2017 10:52 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org>; Peter Bowen <pzb@amzn.com><br>
<b>Cc:</b> Kirk Hall <Kirk.Hall@entrustdatacard.com><br>
<b>Subject:</b> Re: [cabfpub] [EXTERNAL]Re: Ballot 190<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">A question, if I might: I’m not understanding the “massive revalidation of all existing domains” part here. My understanding is that if we alter the methods of validation, you would
need to ensure that any applicants from that date forward are validated under acceptable methods, which may mean searching your database of validated domains and marking some as requiring revalidation, but that shouldn’t require you to
<i>immediately</i> revalidate them unless they’re applying for a certificate…or should it?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">That is, if I’ve previously validated “<a href="http://www.example.com">www.example.com</a>” but using a now-unacceptable method, do I immediately need to revalidate “example.com”
the day the ballot takes effect (and revoke its certs if the validation fails?), or do I merely need to ensure that when “[x].example.com” presents a new certificate application after the ballot takes effect, I re-validate them using acceptable methods?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">As a follow-up, let’s assume that yes, I
<i>do</i> need to immediately revalidate all domain information obtained using non-conforming methods, even without a new certificate request in hand. Even assuming that, I
<i>don’t</i> have to re-validate anything that <i>conformed</i> prior to the ballot, right? So we’re talking about finding certificates that are currently valid but were validated using non-conforming methods, which should mean a search of issuance records
to identify now-invalid information and either marking it for re-validation in the future or just biting the bullet and re-validating it right away.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Just trying to unpack the scope of the problem here a bit.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">--
<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">Jos Purvis (<a href="mailto:jopurvis@cisco.com)"><span style="color:#0563C1">jopurvis@cisco.com)</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">.:|:.:|:. cisco systems | Cryptographic Services<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">PGP: 0xFD802FEE07D19105 | +1 919.991.9114 (desk)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;color:black">From:
</span></b><span style="font-family:"Calibri",sans-serif;color:black">Public <<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>> on behalf of Kirk Hall via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
<b>Reply-To: </b>CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
<b>Date: </b>Friday, 28 April, 2017 at 12:37 <br>
<b>To: </b>Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>>, CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
<b>Cc: </b>Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a>><br>
<b>Subject: </b>Re: [cabfpub] [EXTERNAL]Re: Ballot 190<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yes, that’s good information on possible exploits - thanks. That’s why we worked so long on improving BR 3.2.2.4 – as you may recall, I was deeply involved in
that, and very supportive.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">But I’d really like to know if there is evidence that cert “misissuance” occurred in the past because of these potential vulnerabilities. Do you know if there
is any data on that? I think we would need more than one or two anecdotal (and maybe unconfirmable) stories to justify revetting of all outstanding domains by all CAs. The improvements will be implemented over time, on a going-forward basis.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">As Gerv said, there will be significant reluctance to change / improve validation methods in the future if it always requires massive revalidation of all existing
domains, without a showing of actual past abuses and related security concerns.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Peter Bowen [<a href="mailto:pzb@amzn.com">mailto:pzb@amzn.com</a>]
<br>
<b>Sent:</b> Friday, April 28, 2017 9:31 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
<b>Cc:</b> Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a>><br>
<b>Subject:</b> [EXTERNAL]Re: [cabfpub] Ballot 190</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 28, 2017, at 9:06 AM, Kirk Hall via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">1. It appears from various comments over time that your biggest concern about re-use of prior validation data relates to method 3.2.2.4.6 – Agreed Upon Change to Website.
Old method 6 required “Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">New method 6 requires specified content be posted to a<span class="apple-converted-space"> </span>"/.well‐known/pki‐validation" directory, which no CA has ever done (because
this path is brand new, and created for the updated version of this validation method). So prohibiting reuse of data collected under old method 6 will necessarily require revalidation of ALL domains ever validated under old method 6. As I indicated on the
CABF teleconference yesterday, this will require some CAs (including Entrust) to manually review EVERY domain validation we have done to determine which used old method 6, versus other approved methods. This would be a massive undertaking, and something CAs
won’t want to do unless there is a demonstrated security need.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Can you share with us the facts, data, evidence, etc. that leads you to believe that the domain validations previously done under old method 6 pose a significant security threat
to users? Any statistics to back this up? I’m not challenging you, I’m just asking you for data that supports what you want us to do. We are not aware of any instance where we used old method 6 and later discovered that the domain should not have been authorized
for the customer.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Kirk,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I did some research on this back when we were working on ballot 169. See <a href="https://cabforum.org/pipermail/public/2016-April/007504.html">https://cabforum.org/pipermail/public/2016-April/007504.html</a> and <a href="https://cabforum.org/pipermail/public/2016-April/007506.html">https://cabforum.org/pipermail/public/2016-April/007506.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We know that all the following were valid under the old method 6:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Allowing the certificate requester to specify the URI. For example, if the certificate wanted
<a href="http://shop.example.com">shop.example.com</a>, the requester could say “check at
<a href="http://shop.example.com/tmp/uploads/foo.txt">http://shop.example.com/tmp/uploads/foo.txt</a>” for the agreed upon change<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Looking for the change anywhere in the page. The CA would give the requester a token to put on the website and then look for it to appear somewhere on the page. This is a huge problem for sites that have public comments, message boards,
or user-editable content. For example, validate “control” of <a href="http://www.ibm.com">
www.ibm.com</a> by posting a message containing the token at <a href="https://www.ibm.com/developerworks/community/forums/html/public">https://www.ibm.com/developerworks/community/forums/html/public</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Simply looking for the existence of a file by name. For example telling the customer to create
<a href="http://%3cFQDN%3e/adfa24r43aefwaer2442.txt">http://<FQDN>/adfa24r43aefwaer2442.txt</a> and not caring about the content.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Looking for a content to be returned from the server that was included in the URL and not checking the HTTP return code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I would also note that other “old” methods have similar issues. For example, there was no requirement that email validation used a unique token per request. It would have been valid to send an email saying “Does this email work?” to the
domain owner and using an out-of-office auto-reply as proof of “communication”, as the requirement was only “Communicating with” the email address.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Does that help explain the concern?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Peter<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [<a href="mailto:sleevi@google.com"><span style="color:purple">mailto:sleevi@google.com</span></a>] </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Sent:</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Friday,
April 28, 2017 6:09 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com"><span style="color:purple">Kirk.Hall@entrustdatacard.com</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org"><span style="color:purple">public@cabforum.org</span></a>>; Wayne Thayer <<a href="mailto:wthayer@godaddy.com"><span style="color:purple">wthayer@godaddy.com</span></a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>[EXTERNAL]Re: [cabfpub] Ballot 190</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On Fri, Apr 28, 2017 at 1:32 AM, Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com" target="_blank"><span style="color:purple">Kirk.Hall@entrustdatacard.com</span></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>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">One other comment. Remember that for the last few months, new Methods 1-4 and 7-10 were actually included under Method 11 “any other method” after Ballot 181’s
effective date, and that situation will continue until the effective date of Ballot 190. Also, the same is true for any validations that followed old Method 7 “any other method” prior to the effective date of Ballot 169. So be very careful in saying anything
in Ballot 190 that would invalidate validations done prior to Ballot 190 under “any other method” so long as they complied with any of Methods 1-10 of the new methods or Methods 1-6 of the old methods.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I would be open to saying that any prior vetting done under old Method 7 or more recent Method 11 “any other method” must be revalidated upon the effective date
of Ballot 190 IF they did not follow EITHER Methods 1-6 (as the existed before Ballot 169) or Methods 1-10 (as put forward in Ballot 169). In other words, the ONLY validations that have to be redone before the expiration of the re-use period are validations
that were done that did not comply with either old Methods 1-6 or new Methods 1-10. That should flush out any unknown and unsecure validations that occurred in the past.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Not quite, because if you recall, Google's interest in reforming these began with the fact that a website demonstration of control was not secure. That is, 3.2.2.4.6 under pre-169 is not acceptable.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Kirk, given your support for other forms of indicating that a CA has performed extra diligence, such as the inclusion of OV certificates, would you be supportive in general of a means of expressing, within a certificate, conformance with
the 'new' validation methods, so that subscribers can have assurances of the security? <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Public mailing list<br>
</span><a href="mailto:Public@cabforum.org"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">Public@cabforum.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://cabforum.org/mailman/listinfo/public"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">https://cabforum.org/mailman/listinfo/public</span></a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>