On 17 sep 2010, at 12.28, W.C.A. Wijngaards wrote:
> The file is in XML. It is described in
> http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
> I would like to fix its format, as XML string operations are (in my
> opinion) dangerous - especially for a file someone can force
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Thanks for your comments and suggestions, and I'll go and make my
(software-vendor-specific-)pick from them.
Best regards,
Wouter
On 09/17/2010 05:31 PM, Paul Hoffman wrote:
> No, I am sure we don't want to create a forced cross-dependency on
At 12:28 PM +0200 9/17/10, W.C.A. Wijngaards wrote:
>Are you sure that we want to create a cross-dependency on the https
>security for the DNS security?
No, I am sure we don't want to create a forced cross-dependency on https. But
that is far from the only choice.
We are talking about two differ
On 2010-09-17, at 06:28, W.C.A. Wijngaards wrote:
> * The URL that iana published in their description is:
> https://data.iana.org/root-anchors/root-anchors.xml
> * 'widely available trust certificates' to verify the https
We also specified
- http:// URLs (no "s")
- detached OpenPGP signatur
On 17 Sep 2010, at 11:28, W.C.A. Wijngaards wrote:
Are you sure that we want to create a cross-dependency on the https
security for the DNS security?
Depends...
This means the DNS and cert paths are no longer different trust paths.
That might or might not be a bad thing. If the One True TA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi dnsop,
The sentiment over the last week is that retired keys should not be
abused, and trust-history is then gone, with such opposition by WG.
I do have to renew the root anchor when it changes. Let's look at the
'fetch from iana again' method in
At 12:24 PM +0100 9/10/10, Stephen Morris wrote:
>1. Is the situation addressed by the draft - that of a validator that has been
>offline or that has missed an (emergency) rollover needing to reconfigure
>itself - a problem that needs to be solved?
Yes, mostly for the former case. A subset of th
On 2010-09-14, at 13:55, Tony Finch wrote:
> On Tue, 14 Sep 2010, Joe Abley wrote:
>>
>> Doesn't trust-history impose a requirement high standards of operational
>> security for key materials which have long since fallen out of
>> production, and hence extend the possible window for a key compro
At 13:17 -0400 9/14/10, Joe Abley wrote:
As I've mentioned before, the problem I have with trust-history is that
it involves using old keys to make trust decisions about new keys. It
is difficult to believe in the general case that old keys are entirely
trustworthy. Presumably keys are rolled fo
On Tue, 14 Sep 2010, Joe Abley wrote:
>
> Doesn't trust-history impose a requirement high standards of operational
> security for key materials which have long since fallen out of
> production, and hence extend the possible window for a key compromise
> long after the key has stopped being used? Fr
On 2010-09-13, at 10:36, W.C.A. Wijngaards wrote:
> On 09/10/2010 01:24 PM, Stephen Morris wrote:
>>
>
>> 1. Is the situation addressed by the draft - that of a validator that
>> has been offline or that has missed an (emergency) rollover needing
>> to reconfigure itself - a problem that needs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi dnsop,
On 09/10/2010 01:24 PM, Stephen Morris wrote:
> Colleagues
>
> Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust
> Anchor History Service) is a working group item and the editor has
> received a number of private comments on
Colleagues
Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust Anchor History
Service) is a working group item and the editor has received a number of
private comments on it, there has actually been relatively little discussion of
the draft on the list, either pre- or post-adoption
13 matches
Mail list logo