<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 14 (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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* 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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the #10 use case Gerv was discussing, the certificates are self-signed, so the TLS-ness doesn’t provide much value, so it doesn’t matter where the TLS terminates.
If we’re going to allow that, I think we should make it explicit what we’re allowing (self-signed or untrusted certificates), and also enforce the .well_known requirement for the same reasons why we did it for #6.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">However, on the validation working group call, another use case was discussed, where validation *<b>does</b>* matter, however the validation is against a non-publicly
trusted root (basically, the web site installs a test cert to prove they control the certs for the domain). It’s an interesting use case that I think should be allowed, though I think it should be a separate enumerated method because the security model is
different.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think #10 needs to be tightened up and clarified significantly. I’m sure this will be discussed extensively on the validation WG call in two weeks.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Tim<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Thursday, May 07, 2015 12:07 PM<br>
<b>To:</b> Tim Hollebeek<br>
<b>Cc:</b> CABFPub; Anoosh Saboori<br>
<b>Subject:</b> RE: [cabfpub] Domain validation<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><br>
On May 7, 2015 6:47 AM, "Tim Hollebeek" <<a href="mailto:THollebeek@trustwave.com">THollebeek@trustwave.com</a>> wrote:<br>
><br>
> I’ll note that if you object to #6 on those grounds, you also object to #10, which is basically “do #6 via TLS, with fewer requirements around where the value must be placed.”<br>
><br>
> <br>
><br>
> In fact I’m starting to think that #10 should be eliminated and rolled into #6, simply by noting in #6 that for the purposes of #6, TLS with an untrusted server certificate can be used in place of HTTP.<br>
><br>
> <br>
><br>
> -Tim<br>
><o:p></o:p></p>
<p>No Tim, they aren't equivalent under the threat model / equivalency that Anoosh agreed as (part of) the concern.<o:p></o:p></p>
<p>In both the Azure and the AppEngine case, the hosting provider terminates TLS, and thus the tenant cannot influence it.<o:p></o:p></p>
<p>This isn't universal for all hosting scenarios (e.g. Google Compute Engine, AWS), but it does represent a material difference to the threat model that we should not consider them equivalent.<o:p></o:p></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</body>
</html>