Re: Multiple OpenPGP messages per file: legal or not?
2007-10-08 06:22:34
Rachel Willmer wrote:
By stopping short of how the sequence of bytes is stored or
passed, OpenPGP ensures that it is applicable and
interoperable across a wide range of apps ... just by
forcing the developers of the apps to agree on a few local
details.
"just" ???
Well, like I say, the spec has to stop somewhere. Consider
that once you cross the boundary, you enter into the
argument of MIME v. Ascii Armour, and that's a never-ending
barrel of worms. In fact, it even made an appearance in the
recent message from the IETF where there was a ham-fisted
and embarrassing attempt to downgrade AA in favour of MIME.
Now, this brings up an interesting direction: if you feel
that this area should be more standardised, the MIME
approach of a separate RFC is a good one. Start a files
format RFC.
That argument implies 3 things:
a) it's acceptable to require every implemention to support each other
implementation as a separate special case
Well, no, the spec stops before the application level.
Applications will need to do some extra stuff there, and if
GnuPG creates a format that can't be read by PGP Inc's email
program, then that's an app issue. GnuPG is an app that
happens to include an implementation; it's not just an
implementation.
b) it's acceptable to require each user to specifiy at the time of
encryption or signing which implementations (not algorithms, or keys,
but implementations!) should be able to parse the result
Applications do have that issue to deal with, yes.
E.g., PGP Inc's email program can't read the messages in
Jabber's chat implementation of OpenPGP ... but that's
because it can't read chat, and Jabber clients can't read email!
c) it's acceptable for 2 implementations which support the same set of
algorithms and have the appropriate keys for sharing encrypted or
signed data to say they both have an OpenPGP-conformant application -
but which can't actually share the data.
Yes, that's always acceptable. There is no law that says
that apps have to communicate, only specifications that say
"if you can share these bytes, then we know of no reason you
can't communicate."
Am I the only one that thinks this is a flawed argument?
I would say you would find many friends in the developer
community :)
Surely this should be a fundamental purpose for the standard: for you
to be able to encrypt a file using your implementation, send it to me,
and for me to be able to decrypt it with a different standard.
Isn't it??
I see it a bit of a pipe-dream. If I can send you an
OpenPGP encrypted email that you can decrypt, *guaranteed*,
then that also means that OpenPGP has to specify enough of
the mail system that it can survive various munging effects.
Line-slicing, 7 bit transformations, conversion into
different messaging systems like LotusNotes, ISPs inserting
adverts in freemail, etc etc ... Ascii Armour was an
*attempt* at that, and it works, sort of, but not well
enough to be proud of. MIME was another attempt, and it
suffers its own set of problems. Neither of these attempts
guarantee communicability, they just assist if you are
prepared to work with their assumptions.
A spec would not be able to be so conveniently loose ;)
As someone who is trying to write a set of interoperability tests for
my own implementation, I'm not sure I quite understand your use of the
word "convenient" here... :-)
Right. Literally, your pain is there because OpenPGP threw
the problem over the wall, and you're on the other side of
that wall. What I'm saying is that the wall is actually in
a good place, so please don't throw it back :)
Rachel
P.S. I can take the argument that says a keyring is different, because
it's local to the app. But surely, not encrypted/signed files???
Hmm.... Consider this delicious example of a signed file:
http://webfunds.org/ricardo/contracts/webfunds/BeerVouchers.html
What would it mean if there were *two* such sequences in the
one file? Does the order matter? Is there any meaning to
what comes before or after that data stream? Does the file
creation date mean anything?
In that example the app benefits from OpenPGP's decision to
concentrate on the byte-stream definition. The app then
arranges matters locally to extract out the byte-stream and
deal with it, knowing that it is dealing with one and only
one chunk. In that case, the app certainly ignores any
follow-on packets, and/or declares an error, and it
certainly doesn't want OpenPGP telling it to expect an
endless stream of them.
(We could also talk about signed transactional messages
being concatonated ... or about Java's J2EE where files are
considered not part of the system ... or mobile ... or ...)
iang
|
|