[openpgp] personal review of draft-06

[Stephen Farrell <[e-mail]>]

Hi all,

I gave draft-06 a full read through (which took quite a
while;-). I didn't find any showstoppers but there are a
few things below it'd maybe be worth the WG considering as
well as some nits the editors can handle as they see fit.

Note that this is just me commenting as a participant,
not as co-chair, so these comments deserve just as much
or little considerations as anyone else's.

Cheers,
S.

PS: If some of these warrant being tracked as issues,
we can do that, and collating the recent list discussion
into a set of tracked issues is next on my list for this
stuff, so more on that in a day or two.

possibly interesting comments/questions:

(1) fix intended status == stds track in tracker
(that's on the chairs)

(2) section 1.1/10: "specification required" implies
we'll need designated experts, dunno if we have those
already or not? Doesn't need attention now, but IESG
will pick some down the road sometime.  It looks from a
quick glance at iana.org [1] that we don't have any as
of now for the one current table that'd need 'em.
Can/should we give any generic guidance to the IANA
experts that'll be needed when people want to add new
registrations? Just as an example, we could consider
asking them to be conservative (or accommodating) if
asked to add new algorithms where there's no history of
relatively widespread successful usage.  Or, we could
ask experts to only add things where there's evidence
that implementations exist and are deployed, etc.  Such
text would not use "MUST" etc but can be useful
guidance when an expert is asked to do stuff - they can
push back then and say "the WG didn't want that" which
could be useful.

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

(3) 3.7.2 - we don't have any "MUST implement" here -
is that intended? Argon2 is RECOMMENDED to use but I
didn't see any MUST (or missed it:-). I guess one could
argue that a MUST isn't needed there for interop but
nonetheless maybe worth considering.

(4) 5.2.4: "When a v5 signature is made, the salt is
hashed first." That seems ambiguous, does it mean the
salt is prepended to hash input, or the H(salt) is
prepended to hash input, or H(salt) is prepended to
hash output? I think it'd be better to remove the
ambiguity in case different people do different
things (though that should be clear pretty quickly
so isn't that big a deal).

(5) 5.12.1: If there's deployment already (I don't
know) shouldn't we define e.g. a PNG encoding format
now?  Also, the [JFIF] reference is from 1996! Is that
still correct? (I've no objection to the current text
if that's what's really supported but wouldn't be
surprised if more was commonly supported and there's an
easy opportunity here to improve interop.)

(6) 6.2: Is there an IANA registry to point at for
values to be used for "Charset" ? If so, be good to
have a reference. If not, should there be? (Could be
too much trouble I guess, which'd be a good enough
reason to not take that on.)

(7) 10.2: "RFC REQUIRED" doesn't mean "IETF consensus"
so e.g.  we're currently setup to allow IRTF
experimental RFCs or Independent stream RFCs to define
new packet types and packet versions. Do we want that?
Or would the old IETF consensus setup be more what we
want rather than RFC required?

(8) 11.1.1 (and elsewhere): can many marker packets be
present? Same question for padding packets in 11.4.
The phrasing is a bit ambiguous for me and it could
lead to different implementers doing different things
in a way that'd harm interop and might not be spotted
so easily.

nits/minor stuff:

- general: the version numbers mentioned are a bit
   confusing/all-over-the-place, would it be useful to
   have a table somewhere to help the reader?

- toc: 11.3.2.1/13.3.1.1 stand out as the only entries
   at that level

- 1.1: trademark stuff - is that still accurate? given
   the company was acquired in 2010 maybe not?

- 2.1: the description is very key transport oriented -
   is that still right if we're moving to preferring ECC?

- 3.2.1: missing closing ")" after 12.2

- 4.3 - would it help to have the acronyms used for
   these packet types (PKESK etc.) as a column in the
   table?

- 5.1.3/5.1.4: "MUST make a new PKCS#1 encoding for
   each key" I guess that's related to some timing
   attack or something?  If so, a reference might be
   good.  (Is there a related security consideration?)

- 5.2.3.5 - what does "in a polite manner" mean? Not
   clear to this reader anyway.

- 5.2.3.7 - "may have a" - is that "MAY have a"? (1.1
   would imply not, so just checking it's not an error)

- 5.2.3.7 - "in fact has" seems to me "MUST have" - is
   that right?

- 5.2.3.7 - "user name" - that's the 1st occurence of
   that term - "user ID" is used elsewhere - is that
   deliberate? Or does that need to be defined? (Perhaps
   as (part of) the value contained in a user ID?)

- 5.2.3.7: is "rewriting the signature" clear enough?

- 5.2.3.21: I don't understand the 0x00 entries in the
   1st column of table 9.

- 5.2.3.21: Why is table 10 present but empty?

- 5.2.3.23: "finger"? Really? Should that still be
   there?

- 5.2.4: is "packet packet" a typo?

- 5.2.4: some of the hex literals use upper case, e.g.
   0xB4, while others use lower case, e.g. 0x9a - is it
   worth being consistent there?

- 5.3: "a an" typo

- 5.9: This is probably handled by all implementations
   already but I wondered if there's anything worth
   saying about the characters that can be used in
   filenames? Some OSes/filesystems e.g. don't like a
   colon in a file name. The only reason this could be
   worth a mention would be if some implementation
   commonly truncated the name from the packet (at an
   "illegal" character) when writing to disk which could
   lead to overwriting some sensitive data.  Probably not
   worth a mention though as I'm not sure there's a
   stable enough list of dodgy characters to be useful
   for those creating packets.

- 5.9: Is [PAX] still a reaosnable reference to use?

- 5.10: RFC2822 has been obsoleted by 5322. I don't
   recall that should make a difference but might be
   worth someone checking there're no i18n things in
   5322 that'd cause issues.

- section 7: Should we say we now prefer PGP/MIME?
   (rfc3156) I'm not sure if both that and this
   (cleartext signatures as per this section) are in
   widespread use, so I'm not recommending we make a
   change just asking.

- 9.5: Can we do better than "any recent signature" for
   md5 etc?  Maybe not, but no harm asking:-) We do say
   a bit more for what "old signature" means, but is
   recent == !old?

- 9.5: Does "MUST NOT validate" mean that you must not
   signal that a signature is valid or that you must not
   run the validation algorithm? I assume the former.
   Not sure if it's worth being that bit more precise
   though, is it?

- section 10: would a pointer to 13.11 be useful here?
   (Or to move that text to section 10?)

- 10.2.1.1: I guess we could ask that new image formats
   already have some MIME type assigned as well. Would
   we want that or is it ok as-is?  There are a *lot* of
   such image format at [2] - probbaly more than we'd
   ever want but we could say the ones defined for PGP
   need to be on that list too.

    [2] https://www.iana.org/assignments/media-types/media-types.xhtml#image

- 10.3.1.1: Not sure if referring to the table numbers
   here is right - we probably want to refer to the IANA
   registries by name instead. (Can be fixed later
   though.)

- section 11: typo: "handled strict."

- 11.3.1: should "must" be "MUST"?

- 12.5: Should we add any warnings or requirements
   about the ephemerality of the ephemeral key pair
   "{v, vG}"? Are there cases where those are likely to
   be re-used? (On purpose or by accident.)

- 13.9: "Most ciphers have a block size of 8 octets."
   We can probably delete that now?

- section 14: Table 32 is RSA specific, be good to note
   that just in case. (One could argue to just remove
   the table too though.)

- section 14: comparing cast5 to 3-des nowadays is odd,
   maybe s/3des/aes-128/?

- The I-D nits tool [3] produces some possible things
   to fix or check. (Plus a number of false positives.)
   Those can be handled later though.

    [3] 
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-06.txt

- I also had a glance at the diff vs. RFC4880 [4] (which
   is unexpectedly usable:-) I didn't see anything glaring
   there but the URL might help someone else spot something
   that needs fixing.

    [4] 
https://www.ietf.org/rfcdiff?url1=rfc4880&url2=draft-ietf-openpgp-crypto-refresh-06&difftype=--html