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

[Daniel Kahn Gillmor <[e-mail]>]

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

Please take a look at the HTML rendering
(https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-02.html)
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
here:

  https://github.com/cabo/kramdown-rfc2629/issues/108

I've proposed a formatting workaround:

   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/34

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

   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/35

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:

   https://mailarchive.ietf.org/arch/msg/xml2rfc/6V7C7l-zxg97jRqvuaq8r1QBQqw/

> 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
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/36 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.

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

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:

https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/17

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

    https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml

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 https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/19 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
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/18 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:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/37

        --dkg