Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)

Daniel Kahn Gillmor <> Sat, 27 February 2021 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72BD03A1051 for <>; Sat, 27 Feb 2021 09:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=gG5soR1n; dkim=pass (2048-bit key) header.b=PLLZJYZp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZtEz4MKXL8XB for <>; Sat, 27 Feb 2021 09:46:59 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31A3D3A105A for <>; Sat, 27 Feb 2021 09:46:59 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1614448017; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tfrYPKZIIG7Hke1Ftn6ggYcy5Tz+cXsMDDtir8z8bP0=; b=gG5soR1nnXGqlMJAGxW525M3+kIKhQpZ6d1fxRzUQwc9pYtRPsL3IxfkpAv0Uc5vCcTvC wvXG5Yz22f8K1JSBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1614448017; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tfrYPKZIIG7Hke1Ftn6ggYcy5Tz+cXsMDDtir8z8bP0=; b=PLLZJYZpZgqr6HAAKI2B9i75qUP1TX131M2HwzainKcVdho7cQmdSoItj2cbZ/1JokinY GE+UqfKUBa4uK8Umjk8gqzibHBq6DSzwq70xpjI96a/MVdKSlUvEJ2FrPu2wk0nWro+MnDE +97cffnPnA8Rvh5Pn+3PQXqavrk7degsJQj6nQ1cIVbNl5mBbcjpgNUPtTck2fYPpRJw/wM 0Y6mH0RsN5cW1JYXkmkB+MRM2CxqesG/otmm6RAkXDwNZ3uHLA01Pl4p5aU8b8Dd9K3t6uS 4xq6xQdigGOVYnm4qOComwtgkjIPKlqEU0DjHhy4fqmHk8Me3HVsB4+9K8pw==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 471AAF9A9; Sat, 27 Feb 2021 12:46:55 -0500 (EST)
Received: by (Postfix, from userid 1000) id 9D33E20458; Fri, 26 Feb 2021 23:00:50 -0500 (EST)
From: Daniel Kahn Gillmor <>
To: =?utf-8?Q?=C3=81ngel?= <>,
In-Reply-To: <>
References: <> <> <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Fri, 26 Feb 2021 23:00:49 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Feb 2021 17:47:02 -0000

Thanks for this close read, Ángel.

You raised so many points in one message that i'm afraid some of them
might get lost.

I'm trying to address all of your concerns, either with a merge request
(MR) with a simple editorial patch, a call for further discussion, or a
new issue in gitlab.

If you want to follow up on one or the other, i recommend referring to
the specific issue or merge request in the subject of the mailing list
thread, if one exists.

I encourage folks to do this kind of tracking/triage on the issues they
raise on-list directly, it's quite a bit of work to make sure that all
the points get tracked so they can be handled.

On Fri 2021-02-26 02:25:49 +0100, Ángel wrote:

> 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

I'm not sure how to address this request without doing some heavy
lifting in the toolchain, espcially since it looks like you want the
tooling to behave differently for characters in the two different

Please take a look at the HTML rendering
which sets off these literal string representations in a clearly
different style.  I think that's an improvement worth keeping.

I'm also not sure how much single vs double quotes matters here.  If you
want to propose a fix we can discuss it though :)

> 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.

hm, yes, this looks like a bug in kramdown-rfc2629 which i've reported

I've proposed a formatting workaround:

-Dash-escaped cleartext is the ordinary cleartext where every line starting with a dash `-` (0x2D) is prefixed by the sequence dash `-` (0x2D) and space ` ` (0x20).
+Dash-escaped cleartext is the ordinary cleartext where every line starting with a <u>-</u> is prefixed by the sequence <u>-</u> and <u> </u>.

This results in  the following change in the .txt version:

    Dash-escaped cleartext is the ordinary cleartext where every line
-   starting with a dash "-" (0x2D) is prefixed by the sequence dash "-"
-   (0x2D) and space ` ` (0x20).  
+   starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the
+   sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020).

Hopefully that is no less clear than before, and the rendering is more
normalized without the backticks.

> In appendix A, an extra space was inserted between "Philip R." 
> and "Zimmermann" (Appendix C in -02)

I initially thought this was an artifact of the ./reflow script.  I've
added a special case to avoid it while still being able to use ./reflow,
and suggested the fix here:

However, it looks like this is actually a bug in xml2rfc, which wants to
put two spaces between a period and the next sentence.

I've reported this here:

> 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.

These aren't the full RFC names (4880 itself is not "OpenPGP"), they're
shorthand labels, but i agree that they should be normalized to be more
readable.  I submitted the editorial suggestion to make
them "Camellia in OpenPGP" and "Elliptic Curves in OpenPGP".

> 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.

There is a sense that an ECC Curve OID is a subtype of public-key
algorithms, so putting it closer to public-key algorithms is appealing.
But i think this argues not for leaving it as 9.2, but rather as a
subsection of the "Public-key Algorithms" section of the top-level
"Constants" header (i.e. 9.1.1).

fwiw, while we're nit-picking, this section ought to be named "ECC Curve
OIDs" (in the plural)

Seems like there are three choices:

 a) leave "ECC Curve OIDs" as §9.2

 b) make "ECC Curve OIDs" a subsection of "§9.1 Public-key Algorithms",
    i.e., §9.1.1

 c) move "ECC Curve OIDs" to the end of the "§9 Constants", i.e., §9.5

What do other folks think?

> I'm not too keen on the way this section is introduced. I may provide a MR if
> I can come up with something.

Please do propose an MR.

>  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, although that would need
> additional columns.

Good catch!  I'm not even sure what the "Security Recommended" or
"Interoperability Recommended" columns would mean, or what data they
could contain (booleans? textual recommendations?), let alone how we
should populate them for the initial row.

I've opened a ticket to track this as:

> 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?

If you're talking about the Notation Flags registry, it doesn't
currently exist at IANA:

So yes, while the initial values that populate it came from the older,
obsoleted RFC, this RFC *is* the one that is creating the registry.

> 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

Urgh, right, no matter what "elsewhere in this document" isn't helpful.
If there are particular sections, we should be referencing them
directly.  And the interactions between the profiles and whatever MTI
directives we land on seem unclear.

I've opened to try
to keep track of this.

> 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.

Agreed, this is confusing in its new context.  I've opened to make sure we
resolve that.

> You may want to put the temporary Document Workflow appendix as C,
> so that the other two won't need renumbering on publication.

Good call, this is now: