[Trans] Alexey Melnikov's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
Alexey Melnikov via Datatracker <noreply@ietf.org> Thu, 14 March 2019 13:09 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02B1130DC4; Thu, 14 Mar 2019 06:09:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trans-rfc6962-bis@ietf.org, Paul Wouters <paul@nohats.ca>, trans-chairs@ietf.org, paul@nohats.ca, trans@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155256895272.2621.1849917214823286530.idtracker@ietfa.amsl.com>
Date: Thu, 14 Mar 2019 06:09:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/qiURoDHiWrP1l7X3WY9RRvYrWFg>
Subject: [Trans] Alexey Melnikov's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 13:09:13 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-trans-rfc6962-bis-31: Discuss 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-trans-rfc6962-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this is an important document and I am looking forward to seeing it as a Proposed Standard in the future. However, it has a good number of editorial issues that make the document hard to read and implement. 5. Log Client Messages type: A URN reference identifying the problem. To facilitate automated response to errors, this document defines a set of standard tokens for use in the "type" field, within the URN namespace of: "urn:ietf:params:trans:error:". I think you need to register this in <https://www.iana.org/assignments/params/params.xhtml#params-1> Also, can you clarify whether error need an IANA registry? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: STH is only defined in the table of Content! Please define it early in the document (before the "Changes since v1" section), so that it would be easier to understand for somebody who is new to this. "LSB" is never defined. It might be just me, but I don't know what is the meaning of the ":" operation for an expression "A : B" outside of an index. DER encoding needs a Normative Reference. TLS 1.2 needs at least an Informative Reference. In 4.1: URL needs a reference. In 4.1: What is the typical resolution for Maximum Merge Delay? 10 seconds? 20 minutes? In 4.3: This prevents the CA from avoiding blame by logging a partial or empty chain. "prevents the CA from avoiding blame" reads very awkwardly, maybe rephrase? 4.4. Log ID Each log is identified by an OID, which is one of the log's parameters (see Section 4.1) and which MUST NOT be used to identify any other log. A log's operator MUST either allocate the OID themselves or request an OID from the Log ID Registry (see Section 10.6.1). Various data structures include the DER encoding of this OID, excluding the ASN.1 tag and length bytes, OID encoding in DER really needs a normative reference. 5. Log Client Messages Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all responses are encoded as JavaScript Object Notation (JSON) objects [RFC8259]. Parameters for GETs are encoded as order- independent key/value URL parameters, using the "application/x-www- form-urlencoded" format described in the "HTML 4.01 Specification" [HTML401]. Binary data is base64 encoded [RFC4648] as specified in Please clarify whether you are using Section 4 or Section 5 version of base64. Also, are the trailing "=" expected in values? the individual messages. Note that JSON objects and URL parameters may contain fields not specified here. These extra fields SHOULD be ignored. Why not "MUST be ignored"? This is important for forward compatibility. 8.1.6. Evaluating compliance A TLS client can only evaluate compliance if it has given the TLS server the opportunity to send SCTs and inclusion proofs by any of the three mechanisms that are mandatory to implement for CT-using TLS clients (see Section 8.1.1). Therefore, a TLS client MUST NOT evaluate compliance if it did not include both the Maybe "evaluate" above is a wrong verb, I think "enforce" would be better here. "transparency_info" and "status_request" TLS extensions in the ClientHello. 8.2. Monitor 1. Fetch the current STH (Section 5.2). Repeat until the STH changes. I think the above text should recommend how often the client should poll for this.
- [Trans] Alexey Melnikov's Discuss on draft-ietf-t… Alexey Melnikov via Datatracker