[dnssec-deployment] SEPs and TARs

[Mark Andrews]

In message <list-17541540 at execdsl.com>, Jelte Jansen writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter Koch wrote:
> > On Tue, Mar 31, 2009 at 11:01:26AM -0400, Edward Lewis wrote:
> > 
> > The IANA ITAR is said to fulfill all the requirements and so far I haven't
> > seen an indication to the contrary.
> > (2) above is essential, and in the light of the ITAR and its potential
> > wide used I am concerned about the term TAR being bastardized in a way
> > that is able to undermine users' trust into this technique.
> > 
> > KSK collections are fine -- iff users consent to the consequences they
> > might face.  let's just not name these collections TARs.
> > 
> 
> IMHO, the name TAR is a pretty generic one. Why not use one that implies thos
> e
> extra restrictions, preferably with a 'stable' document to point to so that i
> t
> can be verified, instead of trying to make people use Just Another Generic Na
> me?
> 
> Say, for instance, one would come up with the title "Agreed-upon, Verified, a
> nd
> Actual Trust Anchor Repository" (AVATAR). Then an AVATAR is a TAR, but TAR is
> not necessarily an AVATAR.

	Key scrapings can never be a "TAR" because only the owner
	of the zone can declare that a key is being managed as a
	"trust anchor" rather than as a plain SEP.  "trust anchors"
	have additional constaints above and beyond those of a plain
	SEP.

	DNSKEYS's passed to parents shouldn't be seen as "trust anchors".
	DNSKEYS's passed to DLV shouldn't be seen as "trust anchors".

	The DNSKEYS's passed to ITAR are trust anchors because it
	is known that they will be as "trust anchors" despite IANA
	being the parent.  The DNSKEYS's published at
	https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt
	are trust anchors.  The DNSKEY's published at
	http://ftp.isc.org/www/dlv/dlv.isc.org.key are trust anchors.

	dlv.isc.org is a collection of SEP's some of which are also
	"trust anchors" as they are published by other means.

	I think super TAR's (a TAR which is a combination of other
	TAR's) is fine though please take care not to introduce
	loops.

	Taking a TAR are republishing it in a SEP collection should
	be fine.

	Taking a SEP collection and republishing it as a TAR is not
	fine.

	The only difference between a SEP collection and a TAR is
	the method of publication and with that the different
	constraints on key management.  SEP collections use DNS
	TTL's.  TAR use other timing constraints which will always
	exceed those of the TTL's as the DNS TTL's set the minimum
	requirements.

	Mark
 
> Jelte
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAknTXdcACgkQ4nZCKsdOncUrWQCfeEDpCFuIjUzIGlbhe3Pds/In
> fdgAn1GChyu0GhOMLpHGE60J+q88BQWA
> =SXPp
> -----END PGP SIGNATURE-----
> 
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnss
> ec-deployment/>
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org