Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)
Ángel <angel@16bits.net> Fri, 26 February 2021 01:25 UTC
Return-Path: <angel@16bits.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4F33A13FF for <openpgp@ietfa.amsl.com>; Thu, 25 Feb 2021 17:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl4gzLlGbHnf for <openpgp@ietfa.amsl.com>; Thu, 25 Feb 2021 17:25:52 -0800 (PST)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAAE3A13FA for <openpgp@ietf.org>; Thu, 25 Feb 2021 17:25:51 -0800 (PST)
Message-ID: <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Fri, 26 Feb 2021 02:25:49 +0100
In-Reply-To: <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/nMOv43axRuMzpEVKH3Ijr4-fkuk>
Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 01:25:54 -0000
Hello all After reviewing these two drafts, I agree there are no substantial changes in draft-ietf-openpgp-crypto-refresh-00.txt from rfc4880, and consider draft-ietf-openpgp-crypto-refresh-02.txt good to iterate from. Some specific comments are provided below. Looking forward to seeing you all at the meeting. - Ángel crypto-refresh-00 nitpicks ===== I would prefer to keep single quotes for values referring to single bytes standing by themselves, as rfc4880 did. -00 changed them to double quotes but using single quotes as in C seems better. This happens in * 5.9. Literal Data Packet (Tag 11) ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1") * 6.2. Forming ASCII Armor with '-' and ':' * 7.1. Dash-Escaped Text with '-' but does *not* apply to the characters in 8. Regular Expressions Additionally, in 7.1 a single-quoted space (' ') was converted to use backticks (` `), which seems like an error when converting the document. It makes sense in some markdown conversions, but not in the rfc results. In appendix A, an extra space was inserted between "Philip R." and "Zimmermann" (Appendix C in -02) crypto-refresh-01/02 nitpicks ===== At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in OpenPGP)", since just "Camellia cipher" could be confused with the description itself of Camellia (rfc3713). "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is the preposition used in that rfc title. Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" and would be the proper one if we wanted to use the complete names of the rfc, albeit I don't think that would matter either way. I would prefer to see the new section "ECC Curve OID" as 9.5 instead of 9.2 The other blocks are clear registries used directly. "ECC Curve OID" are a different case since they are actually parameter inside Public key with certain ids. It's probably as 9.2 because a former draft likely referred to it from 9.1, but that doesn't seem to be the case, and is only referred from other completely separate sections. I'm not too keen on the way this section is introduced. I may provide a MR if I can come up with something. 10.2.2.2. Signature Notation Data Subpacket Notation Flags creates a new registry but it doesn't point to a section with initial values. It should probably link to table 7 of section 5.2.3.16, although that would need additional columns. Procedural question: is it the right thing for a RFC to state that it "creates a new registry" for those registries which were actually created by an older RFC it is obsoleting? I feel the text added at 15. Security Considerations still needs some revision. Maybe split part of it to a different section. There are too many things there, and it seems hard to grasp everything it mixes. As a concrete suggestion, I would recommend adding Compatibility Profiles as section 15 instead of 16. Security Considerations (SC) refers to Compatibility Profiles (CP) and Compatibility Profiles refers to Security Considerations, but it seems it would be easier to read Compatibility Profiles first (assuming a linear reading of the rfc). Reference to (SC) is easier to skip (there will be some algorithm choices at that section), whereas the reference to CP is murkier: > Requirement levels indicated elsewhere in this document lead to > the following combinations of algorithms in the OpenPGP profile: > MUST implement P-256 / SHA2-256 / AES-128 / SHOULD implement ... when the reader hasn't been told about OpenPGP profiles and, in fact, some of those algorithms it shows as a MUST are optional at 9.1 / 9.3 An introduction should be added after "16. Compatibility Profiles" and before "16.1" explaining what are Compatibility Profiles and why would they be interesting / needed. You may want to put the temporary Document Workflow appendix as C, so that the other two won't need renumbering on publication.
- [openpgp] I-D Action: draft-ietf-openpgp-crypto-r… internet-drafts
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Derek Atkins
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Robert J. Hansen
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Werner Koch
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Derek Atkins
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- [openpgp] Incorporated RFC 6637: SHA2-384 recomme… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- [openpgp] textual cleanup (no substantive changes) Neal H. Walfield
- [openpgp] Deprecate non-integrity-protected encry… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] Deprecate non-integrity-protected e… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- [openpgp] Sec. Considerations MUST about S2K [was… Daniel Kahn Gillmor
- [openpgp] v5 fingerprints in ECDH brian m. carlson
- [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] Sec. Considerations MUST about S2K … Peter Gutmann
- Re: [openpgp] Curve448 in ECDH Paul Wouters
- Re: [openpgp] v5 fingerprints in ECDH Paul Wouters
- Re: [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] Curve448 in ECDH Paul Wouters
- Re: [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] ECC Curve OIDs section Ángel
- Re: [openpgp] who creates old-rfc registries? Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters