[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[philliph at comodo.com]

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.

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.


The reasoning behind this was that in most cases a CNAME from ‘example.net’ to ‘example.com’ is typically used for internal redirects mapping one service name onto another. An outsourcing relationship, would typically be realized using MX or SRV.

the proposed errata would be to replace the example with the following:


   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

      Alias (Y.Z)

      Z

      Alias (Z)

      Return Empty

   Note that evaluation of an alias is recursive. If Alias (X.Y.Z) = P.Q.R,
   The evaluation of Alias (X.Y.Z) will consist of

      P.Q.R

      Alias (P.Q.R)

      P.Q

      etc.

   Processors SHOULD limit the number of redirections that will be processed 
   to prevent redirection loops or excessive numbers of redirects causing 
   resource exhaustion.




> On Feb 23, 2017, at 6:22 AM, Rob Stradling <rob.stradling at comodo.com> wrote:
> 
> On 22/02/17 22:40, Ryan Sleevi via Public wrote:
>> On Wed, Feb 22, 2017 at 2:32 PM, Doug Beattie via Public wrote:
>> 
>>    Several people have looked at RFC 6844 and have come away with
>>    different interpretations of what the processing means, so I HIGHLY
>>    recommend we include the CAA processing that MUST be performed so
>>    there is no ambiguity and so it’s clear for auditors.  This includes
>>    statements like:
>> 
>> 
>> Hi Doug,
>> 
>> This is and remains problematic, and it doesn't seem the previous
>> feedback was addressed. This is a bit like the recent remarks Virginia
>> shared with offering interpretation of legal matters - while it's meant
>> well, it introduces new problems.
>> 
>> Perhaps you would consider filing IETF errata on what you think is
>> unclear? I'm sensitive and appreciate the concern that technical
>> documents may be hard to understand, I think RFC5280 and the
>> (non-)compliance by CAs is ample evidence that no matter how unambiguous
>> things are, people will misinterpret and misunderstand.
> 
> Doug, Ryan,
> 
> I fully agree that https://tools.ietf.org/html/rfc6844#section-4 is confusing and needs to be revised.
> 
> 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!
> 
> Last week Phill told me he would write an erratum for RFC6844 section 4 this week.
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170224/e9984c69/attachment.html>