OpenPGP Message Format
RFC 4880

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

Comment (2007-05-07)
No email
send info
  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",
  > document are to be interpreted as described in RFC 2119.
  > 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

Comment (2007-05-07)
No email
send info
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

Comment (2007-05-03)
No email
send info
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:
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
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?

(Cullen Jennings) (was Discuss) No Record