>Are there cases of "corrupted" registries make the threat of "stolen zones" a
>real thing?
I think the most well known example is the US government taking the .org domain
of Rojadirecta.
https://torrentfreak.com/u-s-returns-seized-domains-to-streaming-links-site-after-18-months-120830/
There w
The root KSK rollover project has given me a real appreciation for the
brittleness of trust anchor configuration, even with RFC 5011. (Automated
update support should get better over time, especially after the first KSK roll
exposes problems, but right now it's pretty shaky, which is my informed
On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson wrote:
> The root KSK rollover project has given me a real appreciation for the
> brittleness of trust anchor configuration, even with RFC 5011. (Automated
> update support should get better over time, especially after the first KSK
> roll exposes prob
On 2 Nov 2017, at 8:04, Bob Harold wrote:
I generally agree with you, but wonder if there is a performance
penalty to
searching every possible path before failing. Is that a reasonable
concern?
These are reasonable questions, ones that were actively discussed in the
PKIX world 20+ years ago
On Thu, Nov 2, 2017 at 11:04 AM, Bob Harold wrote:
>
> On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson wrote:
>>
>> The root KSK rollover project has given me a real appreciation for the
>> brittleness of trust anchor configuration, even with RFC 5011. (Automated
>> update support should get better
On 11/2/17, 11:04, "Bob Harold" wrote:
>I generally agree with you, but wonder if there is a performance penalty to
>searching every possible path before failing. Is that a reasonable concern?
There are a bunch of tradeoffs to consider. (I'll start with "it is a concern"
but not sure if it's
On 11/2/17, 11:27, "DNSOP on behalf of Warren Kumari" wrote:
> Having a (per-TA) knob sounds like a nice compromise, but I'd really
> like implementors to chime in on how much complexity this adds. If *I*
> added a local TA for .example (or foo.example.com) I'd automatically
> assume that this is
Bob Harold wrote:
>
> How many paths are there? I can think of:
> 1. To the root
> 2. To a local trust anchor
These are actually the same path since you'll find the relevant local
trust anchors in the process of walking down from or up to the root.
(Or, down from or up to the closest enclosing v
Paul Hoffman wrote:
> On 2 Nov 2017, at 8:04, Bob Harold wrote:
>
> > I generally agree with you, but wonder if there is a performance penalty to
> > searching every possible path before failing. Is that a reasonable concern?
>
> These are reasonable questions, ones that were actively discussed i
On 2 Nov 2017, at 11:04, Bob Harold wrote:
> I generally agree with you, but wonder if there is a performance penalty to
> searching every possible path before failing. Is that a reasonable concern?
I think there's a much bigger performance penalty from returning an error to an
application an
Hi Shane,
thanks for the reply and feedback, we do really appreciate :D For the
replies to your comments, see inline.
Again, thanks!
On 10/30/17 3:23 AM, Shane Kerr wrote:
Dr. Pala,
[...]
Some minor points, and then on to major issues
Section 6.3, "Time Validity" might be tricky. Someo
(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 policy" may have more
than one scope.
I.e. Inside a bi
This is only about which trust anchors applies for a given name with
you have several configured with different names. Multiple trust
anchors with the same name is still any match will do.
There are enough senarios where you want *only* the closest
trust-anchor to apply that that is what was cod
13 matches
Mail list logo
