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

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



Ian G wrote:
> 
> Rachel Willmer wrote:
>> On 08/10/2007, David Shaw <dshaw@xxxxxxxxxxxxxxx> wrote:
>>> On Sun, Oct 07, 2007 at 11:41:25PM +0100, Rachel Willmer wrote:
>>>> If (d) "out of scope", which spec does define file formats?
>>>>
>>>> If the answer is "there isn't one which does", how do we plan to do
>>>> interoperability between applications which use the OpenPGP packet
>>>> format? e.g. to transfer Encrypted Messages.
>>> I didn't quite mean "out of scope" in that sense.  I meant "the spec
>>> doesn't mandate it or forbid it, so it's up to the implemention to
>>> decide."  As you saw, GPG doesn't do it.
>>
>> It shouldn't be up to the implementation to decide (IMHO). If the goal
>> of the WG is "to provide IETF standards for the algorithms and formats
>> of PGP processed objects", then surely some standard file formats
>> should be defined [*] : e.g. keyring, encrypted file, signed file,
>> etc.
> 
> 
> The architectural imperative here is that the definition has to stop
> somewhere.
> 
> Stopping before the file / message level is a good idea because if you
> stop after the file level, you also have to define what a file is [*]. 
> I'm sure the theoreticians will describe this more clearly than I .. but
> files aren't necessarily just a sequence of bytes.  Emails aren't
> necessarily the same as files.  Chat messages are different to emails. 
> Who knows what the next innovation in storage or communication will ask
> of us.
> 
> 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.

I think this entirely misses the point - the question is not how
messages are stored/transmitted, but what an implementation should do
when some unit of storage/transmission contains more than one message.

It seems entirely reasonable to me that it should be expected to keep
eating messages until there are no messages left to eat, however the
spec does not state that. It seems to me that it could, quite easily.

> 
> Also, files like keyrings are not the subject of interoperability in
> normal security practice.  The app owns its keyring, and it doesn't want
> to let anyone touch it, it's a bit of a historical accident that the PGP
> keyring was so easy to share.  If there is a need to converse with
> another app, then they should use an export/import format, and there are
> well-defined export sequences in the spec, so that the app has a chance
> to deal with any complications of sharing its internal data.
> 
> 
>> Rachel
>>
>> [*] I'm using "file format" in the loose sense of disk file or file
>> stream.
> 
> 
> A spec would not be able to be so conveniently loose ;)
> 
> iang
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff