Subject: Re: ISSUE 2: Mandatory to implement

From: [email-masked]
Date: Wed, 15 Mar 2006 18:34:10 +0000

some kind soul said:

# Another way of phrasing is:                                                         
#                                                                                     
# This would be the "mandatory to implement" mechanism for everybody who would        
# want to perform automatic rollover of DNSKEYs. Section 5.6 just says that           
# you may choose not to perform automatic rollovers.

	and i guess that i am of two minds here.

	) from a DNS protocol perspective, rollover of keys is pretty much out of 
	  scope.  Its a non-dns issue.  the specs are (mostly) done - lets get
	  the show on the road... time's a wasting.

	however....

	) trust is not a provable mathmatical construct...  welcome to faith-based
	  networking!  operationally, in the absence of a published method on how
	  a delegation point expects to roll its keys (if ever) will impact how
	  its clients and "passers-by" view the integrity of the zone data.  without
	  some rigourous and fairly complete statement by the delegation holder 
	  on the issues of rollover, i expect interest in dns with the added 
	  majik DNSSEC bits to be lukewarm at best.  

	and therein lies the rub.  the IETF (imho) is ill-equiped to dictate 
	operational processes/proceedures.  They have never been very good at it
	and current actions suggest they are not getting better with practice.
	I'm not really in favor of the the IETF tryingto create YABCP that is
	late, flawed, and in most other respects out of touch w/ current operational
	realities.

	I'd be happy if the IETF limited itself to some simple statement along the
	lines of "For delegations that chose to implement DNSSEC features, it is 
	suggested that a docuement be made available that describes the key 
	management protocols, including how key-rollover is to be done. Such
	documentation will be critical for third parties to be able to evaluate
	the integrity of the chain of trust in following key/signature pairs to 
	a known trust anchor"... 

--bill (malcontent)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>