-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I posted a new version of this document. It's a rather small change
compared to the -01, see the rfcdiff:

        
http://tools.ietf.org/rfcdiff?url2=draft-mekking-dnsop-dnssec-key-timing-bis-02.txt

I would like to take the opportunity to initiate a discussion on the
differences between the current key-timing document and this proposed
bis document, and ask the wg if they think these differences make sense.

Thanks and regards,
  Matthijs


Key States
- ----------
My biggest concern is, something that I have mentioned repeatedly,
the definition of key states are overloaded. This issue is introduced by
the term "associated information". A good example of that imo is the key
state Published: In some rollover methods it means the DNSKEY record is
published in the zone and in other methods it reflects the publishing of
RRSIG or DS records. However, if RRSIG records are being published, the
key is being used for signing as well. According to the key state
definitions, the key could have been in the state Active as well. I
expect that it will become worse when we try to use the key states to
define STSS/CSK rollovers.

That's why I proposed to unravel the key states, so that the state of
all "associated information" is representated separately. This is
described in section 2.2 of the key-timing-bis document.

The new set of key states are presented in section 2.3. As a consequence
of unraveling the key states, there are now more states,
but their descriptions are more precise.

Key-centric logic vs Rollover-centric logic
- -------------------------------------------
The timelines in the key-timing document show the events in the lifetime
of a key. Those events are different per key type and rollover method.
However, any key rollover can be thought more or less of the same
following sequence of stages. This concept is described in section 3.1.

Instead of showing timelines that follow the the lifetime of a single
key, now the timelines of a single rollover process is shown. The
timeline starts with an already active key and the diagram shows the
steps how that key is being replaced by its successor key.

Additional rollover methods
- ---------------------------
With the new introduced terminology, I have described STSS rollovers
(section 3.4), and started text on Policy rollover (section 4), where
changes in the DNSSEC policy trigger changes to be made in the DNSKEY
RRset. This includes enabling/disabling DNSSEC, Algorithm Rollover and
switching from ZSK-KSK Split signing scheme and STSS. I am aware that
section 4 needs more text.


- -------- Original Message --------
Subject: New Version Notification for
draft-mekking-dnsop-dnssec-key-timing-bis-02.txt
Date: Fri, 08 Jul 2011 02:07:08 -0700
From: [email protected]
To: [email protected]
CC: [email protected]

A new version of I-D, draft-mekking-dnsop-dnssec-key-timing-bis-02.txt
has been successfully submitted by Willem Matthijs Mekking and posted to
the IETF repository.

Filename:        draft-mekking-dnsop-dnssec-key-timing-bis
Revision:        02
Title:           DNSSEC Key Timing Considerations Follow-Up
Creation date:   2011-07-08
WG ID:           Individual Submission
Number of pages: 46

Abstract:
   This document describes issues surrounding the timing of events
   related to DNSSEC policy.  It presents timelines for various key
   rollovers and DNSSEC policy changes regarding the key signing scheme.
   It explicitly identifies the relationships between the various
   parameters affecting the rollover process.

   This document updates [draft-ietf-dnsop-dnssec-key-timing] [MM: If
   approved] as it covers timelines for key rollovers in more detail and
   it covers additional key rollover scenarios, including algorithm
   rollover and single type key rollovers.





The IETF Secretariat

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOFtNsAAoJEA8yVCPsQCW59qMH/1SGikfsRJWrw66nfQscGe/1
P+2diVWVwSVj6atk3d6LhBl5AJFBaVKkYr2NR4Ub+ZRQkugcu2XLarjZE13A0uXF
Qse5jhvVJXz6Las6cxnBzrYUlJcNg2ueu2Vq46NP67Lh4eXnjjFJW2wFqbWfzTdg
Cg806XGELnsXQHDtIdvYBnwlZidIZOqVBG2abfeVynbFT39Y3o25rOIo4xluBuEn
F/GII1WJO9YIiUv+hEAHyLbsAeVCn7PWMfN3u09YT2ucmh9wnvod3XNAGYhZdPGF
NLwXDNe7Q2xx6OC5jpmMN+3NLt9qX9N7sZEnyk9OptLpgmy1sEmBQifCpUiMPM0=
=1myT
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to