DNS RRTYPE PARAMETER ALLOCATION TEMPLATE


   A.   Submission Date:

	6/11/08

   B.   Submission Type:
        [x] New RRTYPE
        [ ] Modification to existing RRTYPE

   C.   Contact Information for submitter:
               Name: Jim Reid
               Email Address: jim at telnic.org
               International telephone number: +44 20 7467 6474
               Other contact handles: none
        (Note: This information will be publicly posted)


   D.   Motivation for the new RRTYPE application?

   	Storage of keying material in the DNS is currently limited to
   	keys used for Secure DNS and transaction authentication. This
   	is somewhat limiting. It is possible to store encrypted data
   	in the DNS: for instance in the RDATA of TXT records and some
   	other RRtypes. A scheme for encrypting NAPTR records is
   	outlined in draft-timms-encrypt-naptr-01. Defining an RRtype
   	which can be used to publish the keys relating to this
   	encrypted DNS data would provide an obvious method for
   	clients to retrieve those keys so that the encrypted data can
   	be decoded.


   E.   Description of the proposed RR type.

   	The format and structure of the proposed RRtype is almost
   	identical to a KEY record. The only differences are the
   	values of the record's flags and protocol fields. In the
   	proposed RRtype, the flags field is set to zero and its
   	protocol field set to 1. Further details about the record
   	format and its potential applications is given in
   	draft-reid-dnsext-rkey-00.txt.
		[Note from expert: that was the last available
		draft describing the RRTYPE as of the allocation
		of the type code.]

   F.   What existing RRTYPE or RRTYPEs come closest to filling that
        need and why are they unsatisfactory?

	The KEY and DNSKEY records are identical in format and
	structure to the proposed RRtype. Their semantics are
	different however. These RRtypes cannot be used for
	publishing arbitrary application keys that could be used to
	encrypt DNS resource records. DNSKEY is restricted to
	signatures needed for Secure DNS, DNSSEC. The scope of the
	KEY record was limited by RFC3445 to eliminate sub-typing and
	prevent the RRtype being utilised for arbitrary application
	keys. A new RRtype is therefore needed to permit application
	keys specifically for encryption of DNS resource records to
	be stored and published in the DNS.

   G.   What mnemonic is requested for the new RRTYPE (optional)?
        Note: this can be left blank and the mnemonic decided after the
        template is accepted.

	RKEY

   H.   Does the requested RRTYPE make use of any existing IANA
        Registry or require the creation of a new IANA Sub-registry and
        in DNS Parameters?

	Yes. The proposed RRtype uses the IANA sub-registry of
	security algorithm numbers established by RFC2535 and updated
	by RFC4034. The proposed RRtype does not require any
	modifications to that sub-registry.

   I.   Does the proposal require/expect any changes in DNS
        servers/resolvers that prevent the new type from being
        processed as an unknown RRTYPE (see [RFC3597])?

	No.

   J.   Comments:

   	None.