Brian Dickson 于2017年11月3日周五 上午3:58写道：
> (Apologies for neither top- nor bottom- posting, i.e. not quoting any
> other emails.)
>
> There are corner cases which exist, where desired behavior of some
> resolvers is not possible to achieve.
>
> This mostly has to do with constraints where "local poli
On 11/9/17, 00:01, "DNSOP on behalf of Paul Wouters" wrote:
>"prerogative of the implementer" canont apply to how one defines trust
>in a protocol. You can't have two implementations make different
>trust decisions, especially as most endusers don't control their
>resolver.
The first split I m
On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters wrote:
> On Wed, 8 Nov 2017, Edward Lewis wrote:
>
> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibi
To set up the problem to solve. Asking for points that are missed.
(Purposefully omitting the trailing dot, not talking about 'root' because that
could get confusing.)
Trust anchor for "one/17" (i.e., key_id=17)
Trust anchor for "two.one/145"
Received data for "three.two.one" signed by "two.o
On 9.11.2017 15:39, Edward Lewis wrote:
> To set up the problem to solve. Asking for points that are missed.
>
> (Purposefully omitting the trailing dot, not talking about 'root' because
> that could get confusing.)
>
> Trust anchor for "one/17" (i.e., key_id=17)
>
> Trust anchor for "two.one/
On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote:
> Nice write-up Edward! You have nicely summarized why Mark and me agree
> that validator should use longest suffix match when selecting TA to
> validate data.
+1.
> Things might get even more complicated when negative trust anchors are
