Levi Broderick wrote:
(resending, as the original message seems to be MIA)
Consider the following scenario:
An implementation is parsing a public-key packet. The packet header
gives a body length of 600 bytes; this is then buffered into memory.
The software successfully parses all the data in the packet body -
everything from the packet version number to the final MPI that it was
expecting - and realizes that it has only read 400 bytes.
Even if the public key data was successfully parsed, should the
implementation consider the packet to be malformed and reject the key?
Or should the leftover data be considered optional and be ignored? I
think it makes more sense to error out, but the RFC draft and mailing
list archives seem to be silent on this issue.
This sounds like one of those philosophical questions about
coding, and it may be that the draft would be better off
remaining silent on that question.
The GNU world characterised this as "be precise in what you
send, be liberal in what you read." That is, be
accomodating when finding input. In this context the answer
to the above question is "accept the key."
I think it was Dan Bernstein (?) who said something
different. He said, "in security work, be precise in what
you send, and precise in what you read." So his answer
would be "reject the key."
I like the second answer for security work, but OpenPGP is
somewhat in between these worlds; there are several
implementations and they all have foibles, and the coding
history goes back a long time. It is a fact of life that
there have been "disagreements" on how to interpret certain
things, and differing implementations have had to deal with
it; we can't just "start again" with all the implementations.
How to deal with that world? I would say that (a) your
market will tell you, and (b) you might want a third mode of
"accept but warn" alongside "reject" and "accept."
Finally, the ID has passed the point of minor tweaks. We've
been at this for a decade now. No more changes please, seal
the document and let's move on. I vote NO to any changes,
even without knowing what they are ;)
iang