<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: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.gmail-
{mso-style-name:gmail-;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#44546A;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.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:#44546A'>Ryan, one week may be appropriate for reuse of cached CAA records, but during the face-to-face meeting in Redmond, I realized that the time-to-live (TTL) of the CAA record could make that completely ineffective.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'>RFC 6844 doesn’t provide guidance on what TTL should be used on a CAA, but if a domain owner sets a TTL longer than one week, repeated checks by the CA would be served from cache and wouldn’t be served from the authoritative name server.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'>What do you think of allowing the CA to cache the CAA record for the TTL specified in the record? We could augment that with instructions to domain owners to pay careful attention to the TTL they specify in their CAA records.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'>-Rick<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><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'> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Tuesday, October 25, 2016 8:22 AM<br><b>To:</b> Gervase Markham <gerv@mozilla.org><br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Continuing the discussion on CAA<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'>On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='margin-left:.5in'>I think this is definitely worth exploring, and I am confident we can<br>work out some reasonable parameters. However, I wonder if, if we are not<br>checking CAA at every issuance, it would be wise for CAs to be required<br>to implement a "no more certs, please" procedure where the customer can<br>tell the CA to throw away all cached validation information, including<br>the CAA check results. This could be automated in circumstances where<br>the customer has a login.<o:p></o:p></p></blockquote><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>I think it may also be useful to do this for non-customers, but domain holders.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Consider the following certificate: <a href="https://crt.sh/?id=35360532">https://crt.sh/?id=35360532</a><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>It was issued 2016-09-26 to a customer on Google service's<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Since roughly 2016-03-31, <a href="http://googleusercontent.com">googleusercontent.com</a> has had a CAA record of 0 issue <a href="http://symantec.com">symantec.com</a><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>So why was this certificate issued? Well, as Jacob mentioned in <a href="https://cabforum.org/pipermail/public/2016-October/008576.html">https://cabforum.org/pipermail/public/2016-October/008576.html</a> , Let's Encrypt checks CAA at validation time, not issuance time. Despite our CAA record helpfully preventing any new validations, this particular user had a pre-existing cached validation, according to Let's Encrypt, and so the new certificate was issued using the pre-existing validation.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Ironically/unfortunately, it was this pre-existing validation ( <a href="https://crt.sh/?id=14639682">https://crt.sh/?id=14639682</a> ) that lead us to place CAA on the domain to begin with.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Now, I'm not suggesting Let's Encrypt has misissued this certificate - it's why I've been continuing to call it 'unauthorized' issuance - and with respect to the BRs, everything LE did was correct. In particular, the re-use of cached information is fully permitted in the BRs (as many CAs know). However, from a our perspective, this was certainly 'a surprise' and not intended.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>So if we're going that route, I do believe we need to set a much tighter upper-bound than the currently permissible 39 months. Unlike WHOIS information, for which we know some registrars don't provide or some registries make it considerably more difficult (c.f. the CAPTCHA/OCR issues of Comodo recently), CAA is something that any domain holder can express or maintain themselves, and any CA can query.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>So it seems like one week or so should be the upper-bound to how long this information can be re-used.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>As for how we're dealing with this unauthorized issuance, at least with an LE model, we need to submit every one of these 'unauthorized' certificates as problem reports, and hope that Let's Encrypt agrees with us on the basis of domain holder, and then hope that the associated cached data is thrown away. Further, for what it's worth, the BRs do not require that such cached info be thrown away on a problem report - that's simply Let's Encrypt going above and beyond the BRs to do what is common sense and necessary for security, and which other CAs may not be at that same level of maturity.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'> <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'><p class=MsoNormal style='margin-left:.5in'><span class=gmail->> 2) If a customer has a single base domain and needs to issue 6 million certs</span><br><span class=gmail->> an hour for the various sub domains, then there isn't a way for the CA to</span><br><span class=gmail->> simply accept the base domain's CAA record.</span><br><br>I'm not sure how to address this without changing the way CAA works.<br>AIUI it's specced to work from the requested domain down to the root. So<br>I'm not sure I'd say this problem is "easily solved". Does PHB have a<br>comment?<o:p></o:p></p></blockquote><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>I'm not PHB, but you're absolutely correct that it's "not how CAA works". <o:p></o:p></p></div></div></div></div></div></body></html>