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

[Paul Wouters <[e-mail]>]

On Fri, 26 Feb 2021, Daniel Kahn Gillmor 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.

I agree with this. It would be better.

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

If the single quotes are part of the regular text, wouldn't it just work?

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

Which in itself is pretty archaic and shouldn't be done by default :)
(Althouh the unit fmt command also still defaults to this)

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

Seems reasonable. If no one objects over the next few days we will merge
it in.

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

Indeed, please do.

Thanks for the review, and thanks to dkg for filing the issues raised to
discuss later in the WG.

Paul