Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

Wes Hardaker <wjhns1@hardakers.net> Thu, 03 October 2013 20:49 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBB21F9A90 for <dane@ietfa.amsl.com>; Thu, 3 Oct 2013 13:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6OcM-YQSsm4 for <dane@ietfa.amsl.com>; Thu, 3 Oct 2013 13:49:09 -0700 (PDT)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061621F8C3E for <dane@ietf.org>; Thu, 3 Oct 2013 13:31:28 -0700 (PDT)
Received: from localhost (50-1-19-31.dsl.dynamic.sonic.net [50.1.19.31]) by mail.hardakers.net (Postfix) with ESMTPSA id B6ECF23B28; Thu, 3 Oct 2013 13:31:26 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Warren Kumari <warren@kumari.net>
References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <EACEEB05-2023-4F76-A6FE-A9B2FDC0AA59@kumari.net>
Date: Thu, 03 Oct 2013 13:31:24 -0700
In-Reply-To: <EACEEB05-2023-4F76-A6FE-A9B2FDC0AA59@kumari.net> (Warren Kumari's message of "Thu, 19 Sep 2013 16:18:39 -0400")
Message-ID: <0lpprmumeb.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: "dane@ietf.org list" <dane@ietf.org>
Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 20:49:22 -0000

Warren Kumari <warren@kumari.net> writes:

Looks like a good start and thanks for writing it Olafur!  But it's not
ready for publication without some cleanup.  Too many standard-things
are missing, such as acronym expansion and I'd feel guilty passing it
to the RFCEditors without us having caught such things.

Nits:

1)
   handle any case use in the input> The expectation is that by using
                              ^^^^^^
                              ??????

2) my alternate suggested should descriptions (I like the acronyms themselves):

    +-------+----------+-------------------------------------+-----------+
    | Value | Acronym  | Short Description                   | Reference |
    +-------+----------+-------------------------------------+-----------+
    |     0 | PKIX-TA  | PKIX Validated CA Reference         | [RFC6698] |
    |     1 | PKIX-EE  | PKIX Validated End-Entity Reference | [RFC6698] |
    |     2 | DANE-TA  | Validation TA Reference             | [RFC6698] |
    |     3 | DANE-EE  | Domain-issued certificate Reference | [RFC6698] |
    | 4-254 |          | Unassigned                          |           |
    |   255 | PrivCert | Reserved for Private Use            | [RFC6698] |
    +-------+----------+-------------------------------------+-------------+

                     Table 1: TLSA Certificate Usages

3) intro text (1 sentence?) to sections needed and expansion of other
   acronyms earlier in the document (PKIX, EE, )

4) ideally space align the section 3 records

                             inserted one space here
                             v
   _666._tcp.first.example.   TLSA PKIX-CA CERT SHA2-512 {blob}
   _666._tcp.second.example.  TLSA DANE-TA SPKI SHA2-256 {blob}

5) security considerations

   There is definitely something to consider if someone publishes both
   name records along with number records, and the client only parses
   number records.  What happens with this:

   _666._tcp.first.example.   TLSA 3       1    1        {blob}
   _666._tcp.first.example.   TLSA DANE-TA SPKI SHA2-256 {blob}

   Something needs to be said for that case; what would an existing
   implementation do?  drop both? take one?  Either way, it should be
   discussed/mentioned.

-- 
Wes Hardaker
Parsons