[dnsext] TLSA RRTYPE review - Comments period end Apr 3rd

[Frederico A C Neves <[e-mail]>]

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC6195.

This message starts a 3 weeks period for an expert-review of the DNS
RRTYPE parameter allocation for TLSA specified in
http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt
IANA #550878

If you have comments regarding this request please post them here
before Apr 3rd 18:00 UTC.

Best Regards,
Frederico Neves

--begin 6195 template TLSA--
 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: [e-mail]
    International telephone number: [phone]
    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 the RRtype 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 possible
     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.
--end 6195 template TLSA--
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext