On Jun 17, 2010, at 5:15 PM, Olafur Gudmundsson wrote: > > Proposal #1: > The document should describe both single key and split key operations > and provide real guidance as to when each model is appropriate. > > Here is a draft of parameters that should be used to guide > selection of single vs Role based keys: > parent updatability > child zone importance > child zone size > Algorithm used > Algorithm and key size used?
Other potential parameters: response size (i.e. average response size from zone) update/zone change policy and frequency (considering roles below) negative response method (again, considering roles) > Proposal #2: > The document should describe the different roles keys can function in > and the states each key can be. > > Roles: SEP, Zone signer, Update signer, Negative answer signer (RFC 4470) > > States: Inactive, Active, Revoked > Why not use the same terms from draft-morris-dnsop-dnssec-key-timing-02? Otherwise, I think the proposals are sound. Scott > A key can be in one state but fill multiple roles. > > > An Example: dnssec-test.org is zone owned and operated by me, it is not > an important one. > Right now the parent zone (Org) does not accept DS updates (actually it > does via out of band mechanism) > My registrar may or may not accept DS records after ORG starts > accepting them in the near future. > > In this situation the state of the parent+registrar should push me > towards two key operation. > The size and importance of the zone points towards single key > operation. > > As my operation does not allow me to effectively store the key in the > KSK role differently from the ZKS. > ==> dual key operation does not make sense. > ==> Single offers operational and procedural advantages. > > Thus I sign this zone with a single key. > > The tools I use to sign the zone, by default scream at me for bad > operational model. When I filed a bug report the answer I got back was > "This operation is not in accordance with RFC4471" > > When I commented that RFC4471 was not just the first attempt to > provide operational advice, the answer I got back was: > "You are an smart person and may do the right thing but we need to make > sure others follow best practices". > > I agree with this statement and think this is a responsible position > by the vendor. For this reason I want this document to reflect > that in DNSSEC land multiple good practices exist and there is no > one-solution-fits-all > > Olafur > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop =================================== Scott Rose NIST sco...@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
