On 08/20/2012 01:50 PM, John Dickinson wrote:
> We could rearrange the table to tidy up the description of the
> Double-Signature method but keep the existing names. Would that
> help?
Yes, making a clearer distinction between ZSK Double-Signature and KSK
Double-Signature would help a bit.
//yu
John, all,
On Mon, Aug 20, 2012 at 12:50:55PM +0100, John Dickinson wrote:
> > Saying this does not count as a 'standby key' is confusing in the
> > light that the term key is used rather loosely. Also this text
> > insinuates that it is somehow worse than having a "Double-Signature
> > standby k
Yuri,
Thanks for the feedback.
On 14 Aug 2012, at 09:54, Yuri Schaeffer wrote:
> I reviewed the "DNSSEC Key Timing Considerations
> draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively
> with emphasis on verifying correctness of the rollover timelines. I
> believe these are co
I reviewed the "DNSSEC Key Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively
with emphasis on verifying correctness of the rollover timelines. I
believe these are correct.
A remark:
4. Standby Keys, paragraph 6: "Finally, in the Double-DS method of
rolli
On 24/07/2012 07:53, Matthijs Mekking wrote:
General comment: this is an improvement.
some comments and suggestions below
The "state" of the key frequently depends on the viewpoint, for example
zone may have key in active state but due to propagation delay some
validators may think the key is P
[ Quoting in "Re: [DNSOP] I-D Action: draft-ietf-..." ]
> > While dnsop-dnssec-key-timing provides a fairly thorough
> > background which promotes understanding of the underlying issues,
> > it's still a thorny document to apply to an actual operational
> > event.
> >
> > I think it would be grea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/24/2012 05:11 PM, Joe Abley wrote:
>
> On 2012-07-24, at 07:53, Matthijs Mekking wrote:
>
>> As you might know, I had this idea of unraveling key states.
>> Instead of having states that describe the overall state of the
>> key, we would have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/24/2012 03:59 PM, Paul Wouters wrote:
> On Tue, 24 Jul 2012, Matthijs Mekking wrote:
>
>> But both descriptions may be valid at the same point in time. So
>> I would like to say the key can be Published and Active at the
>> same time.
>
>> 2. A
On 2012-07-24, at 07:53, Matthijs Mekking wrote:
> As you might know, I had this idea of unraveling key states. Instead
> of having states that describe the overall state of the key, we would
> have states for components of the key. How to divide the key into
> components is based on the parts th
On Tue, 24 Jul 2012, Matthijs Mekking wrote:
But both descriptions may be valid at the same point in time. So I
would like to say the key can be Published and Active at the same time.
2. A key can have more than one state at a time.
I would not be in favour or using "states" where there is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Stephen asked me to send this suggestion we had (surfaced from
discussions) to the list. We would like to have input before the
upcoming IETF meeting.
Modification to the key states
==
As you might know, I had this id
After much delay, the -03 version of the key timing draft has been
submitted. It incorporates a number of comments made on-list and
privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred
Hoenes.
Perhaps the most significant change concerns the timing considerations
related to the intro
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : DNSSEC Key Timing Considerations
Author(s) : Stephen Morris
13 matches
Mail list logo
