Do people in the working group support making the change Chris
proposes? It is unlikely to be required by the IESG and is unlikely
to delay the document either way. The question is whether people
believe that it would make the document better.
--- Begin Message ---
<https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=790&filename=draft-ietf-openpgp-rfc2440bis>
The clear signature format in section 7 causes signature crud to appear
in mail readers that do not support PGP. It's my belief that such "crud"
can be harmful to deployment of technology (e.g., user A starts using
PGP sends signed mail to user B who doesn't use PGP but sees lots of
PGP boilerplate around the email so user B complains to user A about this
and user A decides PGP is too much trouble). As the IETF has
standardized a mechanism (RFC 3156) which allows mail clients to suppress
most of the "crud," and this mechanism allows a single piece of code to
gracefully handle both PGP and S/MIME, it's my belief we should recommend
greater use of that mechanism to help support greater deployment of
secure email technology.
An additional benefit of RFC 3156 is gateways that alter whitespace or
encodings will keep their hands off that part of the message in a way
they might not otherwise. The format in section 7 doesn't have that
benefit and is thus somewhat more fragile.
As a result, I am presently voting to abstain on this version of this
document. That means the document may still proceed to publication
unless several of my peers on the IESG choose to also abstain. In short,
I feel strongly enough about this to not help this document progress,
but not so strongly that I'm going to actively oppose progression.
Changing the text to say that RFC 3156 SHOULD be used instead
of the format in section 7 for environments that support MIME
multipart messages would cause me to positively support forward
progression of this document.
Also be aware that a large number of the normative references probably
count as downrefs. If there are any downref sticklers left on the IESG,
it may save time to IETF last call the downrefs in advance if that wasn't
already done.
Section 6 mentions the constant '0x864CFB' while the sample code uses the
constant '0x1864cfb'; which one is correct?
Other nits:
Section 3.7.1.3
Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.
Section 4.2.3
I was confused about packet length vs. body length especially after
reading the last paragraph. Perhaps make sure you've used the terms
consistently.
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?
- Chris
--- End Message ---