[Servercert-wg] Update definition of IP Address Contact in the BRs

[Ryan Sleevi]

On Thu, Feb 4, 2021 at 11:17 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Well, the idea was to do a Reverse lookup
>

Right, that was the part not specified, but implied ;) That's the
language-to-be-improved :)


> It's also not clear to me the motivation of why. I'm hoping you can
> elaborate if there are more concrete arguments in favor other than "for
> consistency". For example, an explanation of use cases that are otherwise
> unmet without this change, particularly since it'll require careful
> language to ensure it does what I believe you're trying to do, but which is
> not yet specified to do so :)
>
>
> I consider this a secure method of contacting the entity that
> controls/owns the IP address space, just as the SOA can be used for forward
> Domain Name lookups as part of 3.2.2.4.2.
>

Unfortunately, I think this introduces unintentional surprises into the
chain, so I'm not sure it's unconditionally good. That is, the SOA is used
for one set of semantics, and this would enable it for a different, and
it's not clear that when the SOA record was established, that delegation
(of TLS authority) was intentional.

The requirement to use the RIRs/LIRs unambiguously establishes a chain of
authority to the "owner" of the IP address (i.e. without delegation).
Introducing the added SOA semantics, particularly if a delegation event had
occurred, might delegate authority otherwise unintended. Using "a new
record" could resolve the ambiguity (by having a strong, explicit signal of
delegation of TLS authority), but that's a non-trivial amount of work :)
That's why "consistency" alone wasn't a very compelling thing, and I was
trying to figure out if the delegation beyond the RIR/LIR level was
intentional.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210204/2b77042b/attachment.html>