ietf-openpgp
[Top] [All Lists]

IESG evaluation of draft-ietf-openpgp-rfc2440bis

2007-05-10 11:55:18




Hi.  The IESG discussed draft-ietf-openpgp-rfc2440bis on today's IESG
call.

The main comment was on document clarity.  The concern is that the
consensus of the IESG is that this document probably doesn't provide
enough guidance that you can make an implementation of Open PGP that
will interoperate just from the information in this document.

I think there are two reasons why this is not the case.  First, it's
not clear the set of mandatory to implement mechanisms is sufficiently
well specified.  Second, there are concerns about document clarity.
Section 11 does come close to explaining how you would take the other
parts of the document and produce interoperable messages.  However I
suspect that if I read only this document I would not get it right on
the first try.

However, the IESG does not want to block an update to an existing
proposed standard.  So, I'd appreciate the working group working and
getting as far as you can to address discusses related to clarity.
However, ultimately, we will publish the document.  We will probably
include an IESG note describing our concern and stating that
significant improvements in clarity would be required to take this to
draft standard.

I think only one person ended up holding a discuss on this issue.
That's an artifact of how the IESG operates.  There was a consensus on
the call today that this is a real issue.

So, please prepare a WG response to the following IESG comments:

Things marked discuss are blocking comments that need to be addressed
in some form.  Things marked comment are offered as input to the WG.
I've already explained to Chris that the WG has considered and
rejected the proposal regarding PGP MIME.  Also, the down reference
issues are not going to be a problem.


   Ron Bonica:
   Discuss:
   [2007-05-10] Echoing Lar's and Magnus' concerns about incomplete
   specification.
   Lars Eggert:
   Comment:
   [2007-05-07] 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.
   Russ Housley:
   Comment:
   [2007-05-07]   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.
   Chris Newman:
   Comment:
   [2007-05-03] 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)?
   Tim Polk:
   Discuss:
   [2007-05-10] This is a DISCUSS discuss.  My apologies for its
   length...
   This document would benefit from additional information on
   cryptographic key sizes.  For
   algorithms that may use a range of key sizes, the document specifies
   a minimum (e.g., section
   13.5 states "An implementation SHOULD NOT implement RSA keys of size
   less than 1024 bits.")
   However, it does not make any further requirements.
   Two conforming implementations could be developed - one that
   processed only 1024 bit
   signatures, and a second that processed only 2048 bit signatures -
   and they would not
   interoperate.  I admit this is a bit of a stretch but it plays into a
   more realistic scenario of
   great concern to me.    Current guidance from a number of sources
   (including RFC 3766,
   NIST's cryptographers, etc.) indicates that 1024 bit cryptography
   should be phased out.
   Consider the case where the reciever has an implementation that only
   supports 1024 bit keys,
   but the sender uses 2048 bit keys for signing messages, based on that
   guidance.
   If I purchase a conforming implementation that only suports 1024 bit
   keys, I may not be able
   to communicate with many organizations in the very near future.
   Consider it a standards
   compliant denial of service attack!  In my opinion, this
   specification should encourage
   implementers to support broad ranges of key sizes, especially for RSA
   and DSA.  I understand
   that this is not normal IETF procedure, but I believe that key size
   agility is important.
   At a minimum, I would like to see this concept appear in the security
   considerations.  It
   might be convenient to present the concept after the table of
   equivalent symmetric key
   strengths from [SP800-57] is given.  Establishing a range of MUST
   implement key sizes
   would be better, but may adversely impact implementations for small
   footprint devices.
   Magnus Westerlund:
   Discuss:
   [2007-05-10] I do agree with Lars about that this specification will
   not produce interoperable implementations, but maybe not for the same
   reasons.
   OpenPGP is used in system where sender and receiver do not have the
   possibility to negotiate feauter support prior to sending a message.
   Due to this I would expect very tight definitions on what must be
   implemented in receivers of openPGP. But already in section 2 it is
   made cleared that a lot of important and fundamental mechanisms like
   compression and RADIX-64 support is not mandated, only recommeded. As
   I see it this is one of the cases is where the decoder specification
   is the most important. As long as the encoder creates something that
   a standard compliant decoder can decode things are fine. The Feature
   option helps somewhat, but still think there is need for improvement
   here.
   I don't see specifying the decoder in this fashion will have any
   impact on the compatibility with the deployed base. The compatibility
   comes into encoding recommendations. And you already have profiles
   over recommend set of behavior to get interoperability given the
   knowledge about receivers and their levels. However without a tight
   decoder spec one will never in the future be able to go beyond the
   recommend sets even when knowing that the decoder will be following
   this specification.
   If the WG has reasons why they can't be better specified, please
   inform me.
   Section 5.2.3.1:
     "An implementation SHOULD ignore any subpacket of a type that it
   does
       not recognize."
   This is one more point where interoperability problems arise due to
   too loose specifications. Either one ignore or not unknowns types.
   Only knowing what will happen in a receiver can one dare to deploy
   new sub packet types. Especially considering that you have a
   mechanism to indicate that sub packet types must be understood I
   don't understand why tighter language has not been used. To me it
   seems that the specification should be written in the following form:
   subpacket types SHALL be ignored unless the "critical" indicator is
   set, in which case an error SHALL be generated.
   section 6:
       OpenPGP's Radix-64 encoding is composed of two parts: a base64
       encoding of the binary data, and a checksum. The base64 encoding
   is
       identical to the MIME base64 content-transfer-encoding [RFC2045].
   Shouldn't this specification use RFC 4648 as reference for base64
   encoding?
     ________________________________________________________________

<Prev in Thread] Current Thread [Next in Thread>