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 mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp