On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" <dnsop-boun...@ietf.org on behalf of p...@nohats.ca> wrote:
> On Oct 31, 2017, at 22:25, Ólafur Guðmundsson <ola...@cloudflare.com> wrote:
>>
>> There are three ways to treat this case:
>> Any-TrustedKey-works
>> ConfiguredKey-trumps-DS
>> DS-trumps-configuredKey
>>
>> But I suspect the middle one is implemented
>It better, it is the only working solution :)
Can you elaborate...why would it be the "only" "working" solution?
I understand that "Any-TrustedKey-Works" would be hard on implementers (I
recall a day when one of the original DNSSEC developers didn't like doing
something because it made the code ugly), but it's the one that maximizes
robustness.
("What if:" The trust anchor manager was off-line during the time when an
Automated Updates [STD 69] revocation was signaled?)
Finding the closest trusted encloser ("trusted" meaning there's a trust anchor
data, as opposed to a simple "closest encloser" determined by existence) is
simple, finding and handling the list of all trusted enclosure points would
make the coding ugly. That's the only rationale I'd see for not follow a
philosophy of "Any-TrustedKey-Works."
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
