Subject: Re: Tag 11 unclear

From: Jon Callas <[email-masked]>
Date: Wed, 11 May 2005 17:19:01 -0700

>    " - 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 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?

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 May 2005 15:29:21 +0100

Jon Callas wrote:
> things, and this is giving latitude, which always means lack of clarity. 
> This dates back at least as far as RFC 1991, which says:
> 
> Which is even less helpful, as it doesn't tell us about the zero option. 
> Unfortunately, this is not only ambiguous, but insufficient.
> 
> 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. 
> preserve the creation time and the modification time, but I'm fussy that 
> way.
> 
> 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 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

---

From: David Shaw <[email-masked]>
Date: Thu, 12 May 2005 11:49:24 -0400

> >but no mention of what if it shouldn't be saved as a file. 0 length,

Isn't _CONSOLE what is used when something shouldn't be saved as a
file?  I'd say zero length just means that the sender didn't give a
file name, whether because the data doesn't have one, or because the
filename is private, or even because it just didn't want to.

I think the 0 option for the literal timestamp is similar - it just
means the sender didn't give a time.  The recipient can interpret that
however it likes.

David

---

From: Jon Callas <[email-masked]>
Date: Thu, 12 May 2005 15:16:15 -0700

> filename is private, or even because it just didn't want to.

No, _CONSOLE means "eyes only." Then you do whatever it is you do for 
eyes only.

> means the sender didn't give a time.  The recipient can interpret that

Again, I think there are three options: data mod date (typically 
meaning its source is a file), encrypt time, and decrypt time. The 
encryptor picks. The decryptor has no way of knowing which of the first 
two was picked.

	Jon