Re: Tag 11 unclear

Jon Callas wrote:
> >    " - File name as a string (one-octet length, followed by file name),
> >        if the encrypted data should be saved as a file."
> >
> > but no mention of what if it shouldn't be saved as a file. 0 length,
> > perhaps?
> That's what I'd do.
>
> > Then:
> >
> >    " - A four-octet number that indicates the modification date of the
> >        file, or the creation time of the packet, or a zero that
> >        indicates the present time."
> >
> > I would _guess_ that it means modification date of the file if there's
> > a filename, the creation time if there isn't. I have no idea what zero
> > is supposed to mean. Nothing, would be the obvious interpretation -
> > "the present time" is nonsensical.
> I think that the major problem is that OpenPGP gets used for a lot of 
> things, and this is giving latitude, which always means lack of clarity. 
> This dates back at least as far as RFC 1991, which says:
>    ... Field (d) [labeled previously as "a time field"]
>    should be the time at which
>    the file was last modified, or the time at which the data packet was
>    created, or 0.
>
> Which is even less helpful, as it doesn't tell us about the zero option. 
> Unfortunately, this is not only ambiguous, but insufficient.
> Let's presume that I've decrypted a packet. If I'm storing that in a 
> file, it seems to me that I should take that time field and make it be 
> the creation and modification date of the file, or now if it's zero. If 
> I'm putting it in a text widget (for example), then obviously I don't do 
> anything as the time doesn't really apply.
> If I am creating a literal packet, I have several options. One is that I 
> take the modification time of the file, assuming it's available. 
> Personally, I think if you're transferring files around, you should 
> preserve the creation time and the modification time, but I'm fussy that 
> way.
> The next option that I have is to put the current time in there. The 
> reason I might do that is if I think I'm leaking data by doing it, or -- 
> whatever. If I don't want to put the modification time of the data in 
> the packet, I can put "now" in there.
The obvious "whatever" is when the source is not otherwise dated, such 
as the user typing at a keyboard, or the output of a pipe.
> The last option is that if I don't want to use *my* now, but the 
> *recipient's* now, I can put a zero in there.
> It's completely up to me to decide for whatever arcane reasons I have 
> which of those is the right thing to do.
> I added to the end of the paragraph there: "It is up to the creator of 
> the packet which of these they use." Does that help?
Not really. My objection to the wording is that it makes no sense. That 
is, the time field has three alleged possible meanings:
a) last modification time of file

b) creation time of packet

c) now

we have no way to tell whether a) or b) is meant, unless we link that to 
the presence of a filename, and having a time field mean "now" without 
saying what "now" is supposed to apply to makes no sense whatsoever.
I can't even see how to fix that and retain the "now"ness - if we say it 
applies to the file or the packet, that's clearly untrue. So what does 
it apply to? The only thing that makes sense to me is to define 0 as 
"the sender has declined to provide a time".
As before, if we can agree on this, I'll produce proposed words.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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