-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A KSK roll for the .gov zone will occur at the end of January, 2011.
This key change is necessitated by a registry operator transition:
VeriSign has been selected by the U.S. General Services Administration
(GSA) to operate the domain name registry for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
An algorithm roll for the .gov zone will occur at the end of August, 2013.
This notice is provided
as a courtesy to the DNSSEC community. No action should be required on your
part.
The .gov zone is currently signed with algorithm 7 (RSASHA1-NSEC3-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On the morning of August 14, a relatively small number of networks
may have experienced an operational disruption related to the signing
of the .gov zone. In preparation for a previously announced algorithm
rollover, a software defect resulted in publ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please note that as of today, the .gov zone's transition from
algorithm 7 to 8 is now complete.
Duane W.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJSOzJ+AAoJEGyZpGmowJiNrssIAKI
- Original Message -
> From: "Matt Larson"
> The new KSK will not be published in an authenticated manner outside
> DNS (e.g., on an SSL-protected web page). Rather, the intended
> mechanism for trusting the new KSK is via the signed root zone: DS
> records corresponding to the new KSK ar
On Thu, 23 Dec 2010, Jay Ashworth wrote:
> > From: "Matt Larson"
>
> > The new KSK will not be published in an authenticated manner outside
> > DNS (e.g., on an SSL-protected web page). Rather, the intended
> > mechanism for trusting the new KSK is via the signed root zone: DS
> > records corresp
* Jay Ashworth:
> - Original Message -
>> From: "Matt Larson"
>
>> The new KSK will not be published in an authenticated manner outside
>> DNS (e.g., on an SSL-protected web page). Rather, the intended
>> mechanism for trusting the new KSK is via the signed root zone: DS
>> records corres
Clearly this will require 3 years of subcommittee conferences in order to prove.
.j
On Sun, Dec 26, 2010 at 11:23, Florian Weimer wrote:
> * Jay Ashworth:
>
>> - Original Message -
>>> From: "Matt Larson"
>>
>>> The new KSK will not be published in an authenticated manner outside
>>> DN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/26/2010 09:07, Matt Larson wrote:
| On Thu, 23 Dec 2010, Jay Ashworth wrote:
|>> From: "Matt Larson"
|>
|>> The new KSK will not be published in an authenticated manner outside
|>> DNS (e.g., on an SSL-protected web page). Rather, the intended
- Original Message -
> From: "Matt Larson"
> On Thu, 23 Dec 2010, Jay Ashworth wrote:
> > > From: "Matt Larson"
> >
> > > The new KSK will not be published in an authenticated manner
> > > outside DNS (e.g., on an SSL-protected web page). Rather, the intended
> > > mechanism for trusting
- Original Message -
> From: "Florian Weimer"
> > That sounds like a policy decision... and I'm not sure I think it sounds
> > like a *good* policy decision, but since no reasons were provided, it's
> > difficult to tell.
>
> I don't know if it influenced the policy decision, but as it is
> Date: Tue, 28 Dec 2010 21:17:57 -0500 (EST)
> From: Jay Ashworth
>
> - Original Message -
> > From: "Florian Weimer"
> > > That sounds like a policy decision... and I'm not sure I think it sounds
> > > like a *good* policy decision, but since no reasons were provided, it's
> > > diffic
- Original Message -
> From: "Doug Barton"
> Now OTOH if someone wants to demonstrate the value in having a
> publication channel for TLD DNSKEYs outside of the root zone, I'm
> certainly willing to listen. Just be forewarned that you will have an
> uphill battle in trying to prove your c
Original Message -
> From: "Kevin Oberman"
> There is no reason that you could not do OOB transfers of keys, but it
> would be so cumbersome with the need to maintain keys for every TLD
> (and, for that matter, every zone under them) and deal with key rolls
> at random intervals and conf
> Date: Tue, 28 Dec 2010 22:34:20 -0500 (EST)
> From: Jay Ashworth
>
> Original Message -
> > From: "Kevin Oberman"
>
> > There is no reason that you could not do OOB transfers of keys, but it
> > would be so cumbersome with the need to maintain keys for every TLD
> > (and, for that ma
On Tue, Dec 28, 2010 at 08:07:22PM -0800, Kevin Oberman wrote:
>
> Yes, having a verifiable source of keys OOB might have a small bit of
> value, but, assuming we get general adoption of RFC 5011, I think it's
> pretty limited value. Of course, this begs the question, how do we do a
> better job o
Jay Ashworth writes:
> - Original Message -
>> From: "Doug Barton"
>
>> Now OTOH if someone wants to demonstrate the value in having a
>> publication channel for TLD DNSKEYs outside of the root zone, I'm
>> certainly willing to listen. Just be forewarned that you will have an
>> uphill
On 29 Dec 2010, at 03:27, Jay Ashworth wrote:
>
> If you do not, then your clients have little hope of spotting insider
> malfeasance changes, no?
No cryptography can expose the difference between data that is correctly signed
by the proper procedures and data that is correctly signed by a cor
On Wed, 29 Dec 2010 15:01:41 GMT, Tony Finch said:
> No cryptography can expose the difference between data that is correctly
> signed by the proper procedures and data that is correctly signed by a corrupt
> procedure.
Amen...
Well, it *would* help detect an intruder that's smart enough to subv
On Wed, Dec 29, 2010 at 11:15:02AM -0500, valdis.kletni...@vt.edu wrote:
> On Wed, 29 Dec 2010 15:01:41 GMT, Tony Finch said:
> > No cryptography can expose the difference between data that is correctly
> > signed by the proper procedures and data that is correctly signed by a
> > corrupt
> > proc
On 29 Dec 2010, at 16:56, bmann...@vacation.karoshi.com wrote:
>
>presuposes the attack was server directed. the DNS-sniper will take
>out your locally configured root KSK &/or replace it w/ their own.
If they can do that then you have MUCH bigger problems than authenticity of DNS
repli
Bill Manning saith:
> who intimated that the OOB channel would be http? since that is based
> on the DNS, i'd like to think it was suspect as well. :)
No it's not, Bill, not *necessarily*; you know better than that. :-)
Cheers,
-- jra
On Tue, Dec 28, 2010 at 11:41:18AM -0800, Doug Barton wrote:
>
> Now OTOH if someone wants to demonstrate the value in having a
> publication channel for TLD DNSKEYs outside of the root zone, I'm
> certainly willing to listen. Just be forewarned that you will have an
> uphill battle in trying to p
On 12/28/2010 14:46, bmann...@vacation.karoshi.com wrote:
On Tue, Dec 28, 2010 at 11:41:18AM -0800, Doug Barton wrote:
Now OTOH if someone wants to demonstrate the value in having a
publication channel for TLD DNSKEYs outside of the root zone, I'm
certainly willing to listen. Just be forewarned
On 28 Dec 2010, at 22:46, bmann...@vacation.karoshi.com wrote:
>
>IMHO, key management should be able to use an OOB channel
>when the in-band is corrupted or overlaoded. Reliance on
>strictly the IB channel presumes there will be no problems
>with that channel. EVER. For me, I
On Wed, Dec 29, 2010 at 02:56:35PM +, Tony Finch wrote:
> On 28 Dec 2010, at 22:46, bmann...@vacation.karoshi.com wrote:
> >
> >IMHO, key management should be able to use an OOB channel
> >when the in-band is corrupted or overlaoded. Reliance on
> >strictly the IB channel presumes
26 matches
Mail list logo
