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?
________________________________________________________________