Subject: [dnsext] Requesting Expert review for RRTYPE application for draft-ietf-dane-protocol-18.

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Mar 2012 12:11:48 -0600

Hi dnsext.

I am requesting Expert review for an RRTYPE allocation for draft-ietf-dane-protocol-18.
I have CCed this to [email-masked] (listed in rfc6195), but seem to remember that posting to DNSEXT is the new, correct(er) process….

W

I have included the completed template below:

-------

A. Submission Date: 12 March 2012

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

   C. Contact Information for submitter (will be publicly posted):
         Name: Warren Kumari 
         Email Address: [email-masked]
         International telephone number: +1-571-748-4373
         Other contact handles:

   D. Motivation for the new RRTYPE application.
        Encrypted communication on the Internet often uses Transport Level
        Security (TLS), which depends on third parties to certify the keys
        used.  The allocation of this RRTYPE will improve this situation by enabling
	the administrator of a domain name to certify the keys used in that
   	domain's TLS servers by publishing information in the DNS.

   E. Description of the proposed RR type.
      A description of tge RR type is in draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record
      ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) 

   F. What existing RRTYPE or RRTYPEs come closest to filling that need
      and why are they unsatisfactory?
      The CERT (37) RR, RFC 4398 is closest. It is not suitable for this particular use as it is not
      flexible enough. It *would* be possiable to shoehorn this into the CERT RR, but would be very
      kludgy.

   G. What mnemonic is requested for the new RRTYPE (optional)?
      TLSA

   H. Does the requested RRTYPE make use of any existing IANA registry
      or require the creation of a new IANA sub-registry in DNS
      Parameters?  If so, please indicate which registry is to be used
      or created.  If a new sub-registry is needed, specify the
      allocation policy for it and its initial contents.  Also include
      what the modification procedures will be.

      This is in the the draft (http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt).
      It is included here for completeness, but reviewers are encouraged to consult the draft
      as the formatting is cleaner.

      #1: TLSA Usages.
        A new registry, "Certificate Usages for TLSA Resource Records".
        The registry policy is "RFC Required".
        The initial entries in the registry are:
	   Value    Short description                       Reference
	   ----------------------------------------------------------
	   0        CA constraint                           [This]
   	   1        Service certificate constraint          [This]
   	   2        Trust anchor assertion                  [This]
   	   3        Domain-issued certificate                [This]
   	   4-254    Unassigned
   	   255      Private use

      #2: TLSA Selectors
      A new registry, "Selectors for TLSA Resource Records".
      The registry policy is "Specification Required".
      The initial entries in the registry are:
         Value    Short description                       Reference
   	 ----------------------------------------------------------
   	 0        Full Certificate                        [This]
  	  1        SubjectPublicKeyInfo                    [This]
   	  2-254    Unassigned
   	  255      Private use

      #3: TLSA Matching Types
      A new registry, "Matching Types for TLSA Resource Records".
      The registry policy is "Specification Required".
      The initial entries in the registry are:
         Value    Short description    Reference
   	 --------------------------------------------------------
   	 0        No hash used         [This]
   	 1        SHA-256              RFC 6234
   	 2        SHA-512              RFC 6234
   	 3-254    Unassigned
   	 255      Private use

   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:
      A number of participants in DNSEXT / DNSOPS (and the DNS Directorate) have been involved in / following / are aware of this work.

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Mar 2012 19:32:52 +0000

> I am requesting Expert review for an RRTYPE allocation for draft-ietf-dane-protocol-18.

I have looked at it from the point of view of John Levine's DNS RDATA
description language and I'm pleased to see it'll be easily accommodated.
(This is equivalent to saying that translating TLSA between wire format
and presentation format it is nice and simple.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire: Westerly 3 or 4. Moderate. Mainly fair. Moderate or good,
occasionally poor at first.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Mar 2012 14:23:03 -0600

> and presentation format it is nice and simple.)

Excellent, thank you.

And Olafur pointed out that, even though I *said* that I was CCing [email-masked], I forgot to.
So, I have just forwarded it to them….

W