<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On the CAA recursive part, I am trying to track down why there is an existing errata that makes a normative change with held for update status.</div><div class=""><br class=""></div><div class="">The issue here is not in the PKIX part, it is what a CNAME/DNAME record means. Different people in the DNS community took different positions. We ended up concluding that the recursive interpretation was the appropriate one, i.e. least likely to cause mistakes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The reasoning behind this was that in most cases a CNAME from ‘<a href="http://example.net" class="">example.net</a>’ to ‘<a href="http://example.com" class="">example.com</a>’ is typically used for internal redirects mapping one service name onto another. An outsourcing relationship, would typically be realized using MX or SRV.</div><div class=""><br class=""></div><div class="">the proposed errata would be to replace the example with the following:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">   For example, if a certificate is requested for X.Y.Z the issuer will
   search for the relevant CAA record set in the following order:

      X.Y.Z

      Alias (X.Y.Z)

      Y.Z

</pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">      Alias (Y.Z)

      Z

      Alias (Z)

      Return Empty</pre><div class=""><br class=""></div></div><div class=""><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">   Note that evaluation of an alias is recursive. I<span style="font-size: 13.3333px;" class="">f Alias (X.Y.Z) = P.Q.R,</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class="">   The evaluation of </span><span style="font-size: 13.3333px;" class="">Alias (X.Y.Z) will consist of</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class=""><br class=""></span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class="">      </span><span style="font-size: 13.3333px;" class="">P.Q.R</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class=""><br class=""></span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class="">      Alias (</span><span style="font-size: 13.3333px;" class="">P.Q.R)</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class=""><br class=""></span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class="">      P.Q</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class=""><br class=""></span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class="">      etc.</span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"><span style="font-size: 13.3333px;" class=""><br class=""></span></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">   Processors SHOULD limit the number of redirections that will be processed </pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">   to prevent redirection loops or excessive numbers of redirects causing </pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;">   resource exhaustion.</pre><div class=""><br class=""></div><div class=""><br class=""></div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 23, 2017, at 6:22 AM, Rob Stradling <<a href="mailto:rob.stradling@comodo.com" class="">rob.stradling@comodo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 22/02/17 22:40, Ryan Sleevi via Public wrote:<br class=""><blockquote type="cite" class="">On Wed, Feb 22, 2017 at 2:32 PM, Doug Beattie via Public wrote:<br class=""><br class="">    Several people have looked at RFC 6844 and have come away with<br class="">    different interpretations of what the processing means, so I HIGHLY<br class="">    recommend we include the CAA processing that MUST be performed so<br class="">    there is no ambiguity and so it’s clear for auditors.  This includes<br class="">    statements like:<br class=""><br class=""><br class="">Hi Doug,<br class=""><br class="">This is and remains problematic, and it doesn't seem the previous<br class="">feedback was addressed. This is a bit like the recent remarks Virginia<br class="">shared with offering interpretation of legal matters - while it's meant<br class="">well, it introduces new problems.<br class=""><br class="">Perhaps you would consider filing IETF errata on what you think is<br class="">unclear? I'm sensitive and appreciate the concern that technical<br class="">documents may be hard to understand, I think RFC5280 and the<br class="">(non-)compliance by CAs is ample evidence that no matter how unambiguous<br class="">things are, people will misinterpret and misunderstand.<br class=""></blockquote><br class="">Doug, Ryan,<br class=""><br class="">I fully agree that <a href="https://tools.ietf.org/html/rfc6844#section-4" class="">https://tools.ietf.org/html/rfc6844#section-4</a> is confusing and needs to be revised.<br class=""><br class="">My understanding of the CAA algorithm has at times been flawed, even after seeking clarification from Phill.  If a document confuses even its authors, then you know there's a problem!<br class=""><br class="">Last week Phill told me he would write an erratum for RFC6844 section 4 this week.<br class=""><br class="">-- <br class="">Rob Stradling<br class="">Senior Research & Development Scientist<br class="">COMODO - Creating Trust Online<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>