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?
____________________________________________________________
____
|
