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 <[email protected]> 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
>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
