OpenPGP Message Format
Note: This ballot was opened for revision 22 and is now closed.
(Sam Hartman) Yes
(Jari Arkko) No Objection
(Ron Bonica) (was Discuss) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Russ Housley) No Objection
Some comments come from the Gen-ART review by Miguel Garcia. These two paragraphs should include references for RFC 2119 and RFC 2434: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119. > > The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME > FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG > APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in > this document when used to describe namespace allocation are to be > interpreted as described in RFC 2434. > There are other RFCs that are referenced by number without including the appropriate reference (RFC 1991 is an example). The document contains this reference [RFC 1950], but it is not included in the references.
(Jon Peterson) No Objection
(Tim Polk) (was Discuss) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund (was Discuss) No Objection
(Lars Eggert) Abstain
I'm abstaining from this document. I believe that it is impossible to develop an interoperable OpenPGP implementation based on this document, because it merely defines a packet format without explaining the semantics of the various fields in a way that would let an implementor design the required program logic. I'm not aware of a companion document that includes that content, either. It is in my opinion inappropriate to publish this document as a Proposed Standard for this reason. I would have no objection with publishing this document as Informational or maybe even Historic.
(Chris Newman) Abstain
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 220.127.116.11 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)?