[openpgp] Éric Vyncke's Discuss on draft-ietf-openpgp-p qc-14: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-openpgp-pqc-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Éric Vyncke INT AD comments for draft-ietf-openpgp-pqc-14
CC @evyncke

Thank you for the work put into this document. As an OpenPGP user, I warmly
welcome this update!

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 2.1

What is the context for the BCP14 terms in the "Requirement" column ? I.e., is
it for implementation and/or deployment ?

Per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/,
SHOULD has to be 'shouldered' by explanations on when to bypass or what are the
consequences of bypassing it.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Abstract

As mentioned by the id-nits tool, RFC 9580 must be listed in the abstract as
being updated.

I am trusting the SEC AD to check that this point will be addressed ;-)

The term 'composite' in this context was new for me and is only explained at
the end of section 1 :-( unsure how to fix this though.

### Section 1

s/The OpenPGP protocol supports/The OpenPGP protocol supports [RFC 9580]/

s/National Institute of Standards and Technology/*US* National Institute of
Standards and Technology/ since "national" does not mean "USA" in the rest of
the world ;-)

Strongly suggest to add a sentence such as "This document updates RFC 9580 by
adding KEM and signature algorithms specified in sections 4, 5, and 6.

### Section 1.2.3

Who is the "we" in `We refer` ? The authors ? the WG ? The IETF ? Please avoid
ambiguities (passive voice is an easy fix). This may occur in other places as
well.

### Section 7.1

Why not a MUST in `An implementation SHOULD use AES-256` as it is followed by
`if all recipient certificates indicate support for it` ?

When can the 2 other "SHOULD" be bypassed ? Please avoid ambiguities per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 11

Add a reference to the IANA registries (e.g.,
https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-public-key-algorithms)
to avoid any ambiguities.



_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]