Below are parts of the original mail thread that have not been put into issues.
This is because these seemed to be separate comments that could not be catched
in
issues, or because the issues seemed to be solved after first reply.
Please correct me when I'm wrong.
As for the DOP issue list. They all contain proposals for a "default" action. I
plan
to edit the document "per default" if discussion stalls and there are no
further
comments.
Personally I hope we can meet submission deadline and have this doc in its last
WGLC
by Paris.
--Olaf
> >----------------------------------------------------------------------
> >
> >>
> >> I don't know what detail you want to include, but you should mention the
> >> sliding scale of performance between master and slave, and a note on what
> >> parameter(s) effect cache performance.
> >
> >Is the detail in the above paragraph sufficient? If not could you help
> >us out with suggestions for text?
>
> Probably enough. I'd be curious to hear from others on this too.
> Maybe I'm glossing over something.
> >----------------------------------------------------------------------
> >----------------------------------------------------------------------
> >
> >>
> >> #3.1 Zone and Key Signing Keys
> >> #
> >> # The DNSSEC validation protocol does not distinguish between DNSKEYs.
> >> # All DNSKEYs can be used during the validation. In practice operators
> >>
> >> Is that true? Is that because DNSKEYs must have the zone key bit set?
> >> I forget how we resolved TKEY stuff the type code roll.
> >
> >What about:
> >
> > The DNSSEC validation protocol does not distinguish between DNSKEYs
> > with the SEP flag set or cleared. Both DNSKEYs can be used during the
> > validation. ...
>
> Probably the original text is better. No reason to mention the SEP
> flag here, I had forgotten that we kept the old KEY RR for TKEY stuff.
>
> >----------------------------------------------------------------------
> >----------------------------------------------------------------------
> >
> >>
> >> #4.2.1.1 Pre-publish key set Rollover
> >> #
> >>
> >> # normal pre-roll roll after
> >> #
> >> # SOA0 SOA1 SOA2 SOA3
> >> # RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
> >> #
> >> # DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
> >> # DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
> >> # DNSKEY11 DNSKEY11
> >> # RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
> >> # RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
> >>
> >> RRSIG11(DNSKEY) RRSIG10(DNSKEY)
> >>
> >> Those too?
> >
> >No.. just as was written.
> >
> >You introduce the key but you do not sign with it yet. You just allow
> >the public key to get "introduced" into the caches.
> >
> >The public key is published but the key's effectivity period starts
> >only at the "roll".
> >
> >I hope this is clear. It is the core of the document.
> >
> >----------------------------------------------------------------------
> >----------------------------------------------------------------------
> >
> >
> >
> >>
> >> #4.3 Planning for Emergency Key Rollover
> >> #
> >> # This section deals with preparation for a possible key compromise.
> >> # Our advice is to have a documented procedure ready for when a key
> >> # compromise is suspected or confirmed.
> >> #
> >> # When the private material of one of your keys is compromised it can
> >> # be used for as long as a valid authentication chain exists. An
> >> # authentication chain remains intact for:
> >> # o as long as a signature over the compromised key in the
> >> # authentication chain is valid,
> >> # o as long as a parental DS RR (and signature) points to the
> >> # compromised key,
> >>
> >> This is a considerable problem. A reminder that DS records ought to be
> >> conservatively signed.
> >
> >
> >Suggestion:
> >
> > o as long as a parental DS RR (and signature) points to the
> > compromised key (also see 4.4.4 DS Signature Validity Period)
> >
> >----------------------------------------------------------------------
>
--
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
