On 07/09/2010 03:32 PM, Hugo Salgado wrote: > On 07/07/2010 04:52 AM, Stephen Morris wrote: >> On 15 Jun 2010, at 14:49, Hugo Salgado Hernandez wrote: >> >>> I have a comment regarding the KSK rollover with the "Double-DS" method, >>> section 3.3.2. >>> >>> The ICANN draft procedure for submitting DS to the root zone require >>> that: >>> "At the time of the trust anchor request, there must be a DNSKEY that >>> matches the DS record present in the child zone. This will be tested >>> for the presence of a matching DNSKEY record as part of the >>> implementation of the record. As with most technical >>> conformance criteria for the root zone, if a top-level domain >>> operator has a situation where this is not the case, but this is by >>> design and can be demonstrated not to affect the stability of the TLD >>> or the root zone, it is possible to request that the trust anchor be >>> listed regardless." [1] >>> >>> >>> But in the Double-DS timeline the DS is submitted in Event 2, and the >>> key "could be" introduced in Event 4. >>> >>> I think it is safe to publish the key N even before Event 2 (but not >>> activate it before Trdy). And like the root procedure, it could >>> be recommended to do this way for any zone whose parent requires a >>> published-matching-key along with the DS submission. >> >> The scenario of publishing the KSK in the child zone before publishing the >> DS record in the parent is what the double-signature KSK method describes, >> and that would better fit the process outlined above. >> >> The KSK rollover methods described in the draft are really extremes: >> >> * Double-signature method describes the case where there is only ever a >> single DS record in the parent zone at a given time; but during the rollover >> there are two KSK DNSKEY records in the child. >> > > But with the Double-signature method, besides the two KSK DNSKEY > records, you need two *RRSIG* records, one with each KSK. > > I think the Double-DS method still fits in the process of IANA, > if we take care that in the child you'll nedd to have the new KSK > DNSKEY record published before submitting your new DS, but not signing > with it. The only KSK RRSIG for the DNSKEY rrset should be with the old > KSK. >
My proposal is to add to the Event 1 in 3.3.2 a paragraph like this: "If the parent zone policy requires a published DNSKEY before accept a DS submission, add the key N into the DNSKEY RRset at this time, (or any time before Event 2) is a standby state (not yet used to sign the RRset)" Hugo _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
