Joe,
Not directly related to this draft ( it's probably out of scope ), but is there
any guidance on the timing of rollover of the Trust Anchor for the Root Zone?
Specifically, how many days/months in advance will a replacement Trust Anchor
be published before the old Trust Anchor becomes
I've taken a look at draft-jabley-dnssec-trust-anchor-00
and have a couple of comments -- mostly editorial in nature.
The items below follow a linear walk-through, independent of
any perceived severity.
(1) Abstract -- nit (punctuation)
For improved readability, I suggest to insert a comma in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Minor clarification in the final table (thanks Wouter). RRSIG_Z_2 in
step 4b and 5 should be RRSIG_K_2.
Matthijs
On 09/30/2010 03:03 PM, Matthijs Mekking wrote:
c) Both a) and b)
Hi Alfred,
On 2010-09-30, at 09:29, Alfred HÎnes wrote:
I've taken a look at draft-jabley-dnssec-trust-anchor-00
and have a couple of comments -- mostly editorial in nature.
Many thanks for the review. I have made changes based on your editorial
observations, and my co-author is working on
(Hat off)
I've had a look at draft-ietf-dnsop-dnssec-dps-framework-02 and have the
following main comments:
Section 4.4 Facility, Management and Operational Controls
There is a lot in here about disaster recovery planning that an organisation
should already have documented. Ought this
Hi Joe,
It is not clear if the validUntil time is referring to the time when the
key is expected to be rolled into RFC 5011 revoked state or when it is
expected to be removed from the zone.
What will happen with the keytag field in the published data for an
historical key that has been revoked?
On 2010-09-30, at 16:51, Stephan Lagerholm wrote:
It is not clear if the validUntil time is referring to the time when the
key is expected to be rolled into RFC 5011 revoked state or when it is
expected to be removed from the zone.
I see what you mean.
What will happen with the keytag
On 2010-09-30, at 18:42, Tony Finch wrote:
I think it was a mistake to drop the trust anchor history draft, because
it has a reaasonably coherent answer to the problem. I think the arguments
that it is not secure enough are misguided. What we want is a way for
software to bootstrap its
At 7:42 PM +0100 9/30/10, Tony Finch wrote:
At the moment the trust anchors are the ICANN x.509 self-signed
certificate and/or the PGP keyring. What are the processes for rolling
over these keys? How should manufacturers of software or hardware with a
long shelf-life use them to bootstrap DNSSEC?
On 2010-09-30, at 19:23, Paul Hoffman wrote:
At 7:42 PM +0100 9/30/10, Tony Finch wrote:
At the moment the trust anchors are the ICANN x.509 self-signed
certificate and/or the PGP keyring. What are the processes for rolling
over these keys? How should manufacturers of software or hardware
On 30 Sep 2010, at 20:23, Paul Hoffman paul.hoff...@vpnc.org wrote:
When you say ICANN x.509 self-signed certificate, do you mean the
certificate used for the https URLs in this draft?
No: see http://data.iana.org/root-anchors/icannbundle.pem and
On 30 Sep 2010, at 21:12, Paul Hoffman paul.hoff...@vpnc.org wrote:
In all seriousness, if a software vendor / distro wants to have a way to do
bootstrapping of the ICANN root over the long term, they should stand up
their own CA for this purpose and distribute their own CSR as part of the
At 12:57 AM +0100 10/1/10, Tony Finch wrote:
Without trust anchor history, you start off with a trust anchor that is
broken, and the only option is to downgrade to insecure DNS and use that to
get the new trust anchor and its signatures.
True, but the new trust anchor you get can be validated
13 matches
Mail list logo
