[Sidrops] Alexey Melnikov's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 10 April 2019 17:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB421200EB; Wed, 10 Apr 2019 10:40:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-https-tal@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155491803396.9216.4105477992064648125.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 10:40:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/vdng9yA7jV-_3pvQkcErbnodI04>
Subject: [Sidrops] Alexey Melnikov's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 17:40:34 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-sidrops-https-tal-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this well written document. I have a few relatively minor
comments (and questions) which I think you should address:

1.  Introduction

   This document obsoletes [RFC7730] by adding support for HTTPS URIs in
   a TAL.

If this document obsoletes RFC 7730, then I think you need to have "Changes
since RFC 7730" section (Is this a BIS document?). If it only updates it, then
the above (and the obsolete header at the top of the draft) is not correct.

2.2.  Trust Anchor Locator File Format

   In this document we define a Trust Anchor URI as a URI that can be
   used to retrieved a current Trust Anchor certificate.  This URI MUST
   be either an rsync URI [RFC5781], or an HTTPS URI [RFC7230].

I think the first mention of URI still needs a reference to RFC 3986.

   The TAL is an ordered sequence of:

   1.  an optional comment section consisting of one or more lines each
       starting with the '#' character, followed by human readable
       informational UTF-8 text, and ending with a line break,

Unless you think you want to use ASCII and Unicode Control characters in this
field, I think you should recommend usage of RFC 5198 here.

2.3.  TAL and Trust Anchor Certificate Considerations

   The trust anchor MUST contain a stable key.  This key MUST NOT change

How does "MUST contain a stable key" differ from "key MUST NOT change"?

   when the certificate is reissued due to changes in the INR
   extension(s), when the certificate is renewed prior to expiration, or
   for any reason other than a key change.

This reads funny: “you must not change the key unless you decide to change the
key”. Maybe talk about key compromise and key strength no longer being adequate
instead?

4.  HTTPS Considerations

   o  This protocol does not require the use of SRV-IDs.

   o  This protocol does not require the use of URI-IDs.

I suspect this was copied from another RFC, but "does not require" is not right
here, as it doesn't prevent it as an option. I think you should change "does
not require the use" to "does not use"