any KSK can be used as a TA. there is no way to know - unambigiously -
that any given KSK is not being used as a TA in some validator.
however, your assertion that at KSK should -never- be rolled unless
compromise is known or strongly suspected is -BAD- from an operational
and liklely from a
On Sun, Sep 28, 2008 at 09:14:38PM -0700, Paul Hoffman wrote:
> In the last paragraph of 3.1.1, change:
>These
>can include the registry of the parent zone or administrators of
>verifying resolvers that have the particular key configured as secure
>entry points.
> to:
>If there
At 10:03 PM -0400 9/29/08, Paul Wouters wrote:
On Sun, 28 Sep 2008, Paul Hoffman wrote:
An attack can only be used if the compromise is unnoticed
and the attacker can act as an MITM in an unnoticed way.
Not at all. Even when noticed, there is still the time before the
majority of the world
On Sun, 28 Sep 2008, Paul Hoffman wrote:
> An attack can only be used if the compromise is unnoticed
> and the attacker can act as an MITM in an unnoticed way.
Not at all. Even when noticed, there is still the time before the
majority of the world has fixed the compromised use for which there
are
At 8:13 AM -0700 9/29/08, Wes Hardaker wrote:
Any key may be used as a trust anchor and
it's impossible for a zone operator to tell whether their DNSKEY's in
their zone are used for trust anchors or not.
Fully agree.
There are plenty of
previously discussed reasons for using a list of trust a
At 6:23 AM -0700 9/29/08, Wes Hardaker wrote:
> On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman
<[EMAIL PROTECTED]> said:
Overall I think the changes seem reasonable. However, I don't think
everything is taken into account... I understand the desire for
removing the specified timing ass
At 12:08 PM +0200 9/29/08, Matthijs Mekking wrote:
I encourage making the 4641 document more up to date and adding better
definitions. However, one issue draw my attention: I am not sure if
doing key rollover in emergencies only is good practice, for a couple of
reasons:
* All keys have an expec
> On Sun, 28 Sep 2008 21:14:38 -0700, Paul Hoffman <[EMAIL PROTECTED]>
said:
Again, I completely agree with the goal of trying to remove some of the
key-rollover requirements because of key-length and usage issues that
are likely bogus. However, I think your proposed edits fail to take
into
- Original Message -
From: "Matthijs Mekking" <[EMAIL PROTECTED]>
To: "Paul Hoffman" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 29, 2008 3:08 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Paul,
I encourage mak
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 28, 2008 9:15 PM
Subject: [DNSOP] Proposed changes to RFC 4641: better cryptography
Remove the second bullet in 3.1.1
In 3.2, add a reference to NIST SP 800-90 after the reference to RFC
4086.
> On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman <[EMAIL PROTECTED]> said:
Overall I think the changes seem reasonable. However, I don't think
everything is taken into account... I understand the desire for
removing the specified timing associated with key-age based on modern
analysis. Bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Paul,
I encourage making the 4641 document more up to date and adding better
definitions. However, one issue draw my attention: I am not sure if
doing key rollover in emergencies only is good practice, for a couple of
reasons:
* All keys have an e
12 matches
Mail list logo
