Re: Where are we (metaphorically speaking)?

[Daniel Massey <masseyd@isi.edu>]

Hi,

Since there seems to be some discussion of KEY changes with
DS, here is the plan we have for cairn.net DS operations

Note this is still a rough draft, but gives a good sense
of how we expect to operate.

Dan

PS DS patch will be ready very soon...

-----------------------

DS is substantial change for previous operations.  Under DS, 
you do not need to know (and will not be informed of) any
key changes at cairn.net.  Similarly, cairn.net does not
need to know your key change policies.  

You simply provide us with a DS set, tell us the maximum 
SIG expiration date for the DS set, and tell us when to 
change the DS set. Within this framework, you can manage 
your keys in any way you see fit. 

Requirements you must meet:
  - you must provide us with a DS set
  - you must tell us when the DS set should expire
  - you must update the DS set before it expires
  - at least one week must elapse between DS set updates

Services we provide
  - changes to your DS set will processed within one week
    from the date received (or within one week of your
    requested start date if start date > received date)
  - your DS set will be available from cairn.net servers and
    will properly signed.
  - the SIG lifetime on your DS set will never exceed the 
    requested maximum**

**  Note the SIG we generate for your DS set may have an
    expiration date less than your requested maximum.  This
    is not an error and is due to local key lifetimes and 
    SIG policies.  We will update the SIG before it expires
    and guarantee to maintain valid SIGs over your DS set 
    up until your requested expiration data.

Recommendations for KEY and DS management
-----------------------------------------

You are free to select any mechanism for changing keys.

***  Changing the DS set stored at cairn.net. *****
 Assume you want to transition from DS 1 to DS 2.  Currently 
 KEY 1 is stored in your zone and DS 1 is stored at cairn.net.
 
 1) At least one week prior to the DS 1 expiration date,
    generate KEY 2 and enter KEY 2 into your zone.
     - your keyset now contains KEY1 and KEY2
     - the keyset should be signed by BOTH KEY1 and KEY2.
     - the lifetime on BOTH SIG records should match the
       intended KEY 1 expiration date.
     - you may use either KEY1 or KEY2 (or both) to sign
       the rest of the zone

 2) Send DS 2 to cairn.net and specify the maximum lifetime for KEY2.

 3) Periodically query the cairn.net zone.  When DS 2 is visible,
    remove KEY 1 from your KEY set.
      - your keyset now contains only KEY2
      - the keyset should be signed by KEY2
      - the lifetime on this SIG should match the KEY2 expiration 
        date.

Note the sequence of changes is intentionally designed to avoid any
synchronization with cairn.net.  You do not need to know precisely
when the DS record is changed at cairn.net.  Just make sure KEY 1
is visible until the DS record changes and the SIG lifetimes don't
expire (just resign if they are about to expire).
    
***Reducing interactions with cairn.net.
  If you want to change KEYs without involving cairn.net or if you
  want to change KEYs more frequently than our one week update allows,
  use a master key.

1) generate a master key, KEY M, for signing your key set.
    - your keyset contains KEY M and KEY local 
    - your keyset is signed by KEY M
    - the SIG by KEY M determines the lifetime of KEY local
    - (optional) KEY local may also sign the key set
    - KEY local signs your zone data

2) send DS M to cairn.net and select a long lifetime.

3) Change KEY local as often as you like.  
    - cairn.net does not know or care when KEY local changes.
    - just insure that KEY M always signs the KEY set.
    - (optional) limit use of KEY M by having it ONLY sign the 
      KEY set.
    - (optional) configure KEY M in trusted key lists.
    - don't forget to update KEY M before it expires

ex: isie.cairn.net uses a 6 month lifetime for KEY M and thus
    interacts with cairn.net twice a year.  The isie.carin.net
    KEY (local) changes at varying rates, between once a month
    to once a day.  cairn.net doesn't know or care about 
    changes to key local (the isie.cairn.net children don't know
    or care about changes to KEY master or KEY local)