[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple OpenPGP messages per file: legal or not?

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

"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 :)


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:


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 ...)