Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. GnuPG>
  3. devel
0.9.0 expiration date: does not work
walterk at dip
Dec 27, 1998, 2:55 PM
Post #1 of 15 (655 views)
Permalink
Moin,

yesterday I created a DSA-Key with an expirationdate of today,
although I can still use it now (after expiration) for signing.

Shouldn't there at least a warning, when trying to use a expired key?


--------------------------------------------------------------------------
walter@dg9ep:/tmp> date
Mon Dec 28 22:24:13 CET 1998
^^^^^^^^^^

walter@dg9ep:/tmp> gpg --edit-key dg9eptest
gpg (GnuPG) 0.9.0; Copyright (C) 1998 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Warning: using insecure memory!
Secret key is available.

gpg: key EA5724F8.1707: expired at Mon Dec 28 15:46:05 1998 CET
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pub 1024D/EA5724F8 created: 1998-12-27 expires: 1998-12-28 trust:
-/e
^ ^^^^^^^^^^
sub 1024g/DB4ED11F created: 1998-12-27 expires: 1998-12-28
^^^^^^^^^^
(1) dg9eptest (expire/revoke) <dg9ep@dg9ep>


walter@dg9ep:/tmp> gpg --clearsign -u dg9eptest -o zz x
gpg (GnuPG) 0.9.0; Copyright (C) 1998 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "dg9eptest (expire/revoke) <dg9ep@dg9ep>"
(1024-bit DSA key, ID EA5724F8, created 1998-12-27)

File 'zz' exists. Overwrite (y/N)? y
walter@dg9ep:/tmp>
------------------------------------------------------------


lot of errors with 0.9.0, maybe i did something general wrong (i486,
2.0.36, glibc2, using a diff)?


Gruss,
Walter
--
Walter Koch Hochdahl am Neandertal
walterk@mail.dip.de ham:dg9ep@db0iz
http://home.pages.de/~dg9ep/ qrv:db0iz-9
Re: 0.9.0 expiration date: does not work [ In reply to ]
wk at isil
Dec 29, 1998, 6:27 AM
Post #2 of 15 (652 views)
Permalink
Walter Koch <walterk@dip.de> writes:

> yesterday I created a DSA-Key with an expirationdate of today,
> although I can still use it now (after expiration) for signing.

I fixed this bug: A warning is now displayed when you verify a
signature whose keys has expired.

It should not be possible to use an expired secret key - I have to
implement this.


Werner
Re: 0.9.0 expiration date: does not work [ In reply to ]
Bodo_Moeller at public
Jan 3, 1999, 9:32 PM
Post #3 of 15 (650 views)
Permalink
Werner Koch <wk@isil.d.shuttle.de>:

> A warning is now displayed when you verify a
> signature whose keys has expired.

> It should not be possible to use an expired secret key - I have to
> implement this.

Warnings are absolutely O.K., but it *should* be possible to use
expired expired (signing or decryption) secret keys. You might want,
however, to introduce a new option that must be used if an expired key
is to be used (so that the user won't do that unintentionally).

One reason is that I might want to decrypt messages that were
encrypted to a now expired key of mine (the expiry means only that
no-one is supposed to _en_crypt messages to that key any more).

Another reason is that operations that _are_ cryptographically
possible should also be possible with the software, if only to save
crypto novices from getting things wrong. If a user wants it to be
impossible to use a certain secret key, then they'll have to delete
it; period. (Similarly, there are utilities that allow deleting
recipients from an encrypted message and that allow adding real or
fake recipients to an encrypted message, where a "fake recipient" is
someone who purportedly can decrypt the message, but whose public-key
encrypted session key packet actually contains only garbage. The
existence of such tools makes it clear that the "recipient list" of
some message does not necessarily mean that the original sender of the
message encrypted that message to exactly those recipients who are
listed. -- Well, at least I _think_ that there are such tools; if
no-one published such things by now, at least they are possible.)
Re: 0.9.0 expiration date: does not work [ In reply to ]
wk at isil
Jan 3, 1999, 10:44 PM
Post #4 of 15 (652 views)
Permalink
Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de> writes:

> Warnings are absolutely O.K., but it *should* be possible to use
> expired expired (signing or decryption) secret keys. You might want,

It is possible:

gpg --edit-key your-key

> expire

and set a new expiration date.
Re: 0.9.0 expiration date: does not work [ In reply to ]
mskala at ansuz
Jan 4, 1999, 8:34 PM
Post #5 of 15 (651 views)
Permalink
On Mon, 4 Jan 1999, Bodo Moeller wrote:
> That's a possibility, but it's somewhat awkward. Also, for decryption
> keys that I keep just in order to be able to decrypt old stuff, I
> would not really want to change the expiration date: The key _is_
> expired, I have no intention to change that -- I simply want to use
> it anyway.

I think it's arguable that using an expired key for decryption should be
allowed *by default* anyway. What exactly does the expiry date mean? It
seems to me that it means "Don't send me any messages to this key, nor
accept any signatures from this key, after this date." After my key
expires I generate a new one for new traffic, but I should still be able
to use the old one to read my old traffic. It should not stop working for
decryption after it expires. On the other hand, it *should* stop working
by default for *signatures*, because if I make signatures with it after
the expiry date then they will look bad to the verifier, and I shouldn't
be able to do that by accident.

I think the Right Thing to do is:

- Signing with an expired key doesn't work by default, does work with a
special option.
- Verifying a signature that appears to have been made by an expired key
after its expiry date but is otherwise good reports the signature as BAD,
preferably with a message indicating that it's a key-expiry problem rather
than a cryptographically bad signature.
- Verifying a signature from a key that is now expired, where the
signature was made before the expiry date, reports the signature as
GOOD, possibly with a warning that the key has since expired.
- Encrypting to an expired key doesn't work by default, does work with a
special option.
- Decrypting always works, if you have the appropriate secret key and
passphrase.

The third girl had an upside-down penguin on Matthew Skala
her stomach, so the doctor told her, "I'll Ansuz BBS
examine you for free, if you and your (250) 472-3169
boyfriend will debug my Web server." http://www.islandnet.com/~mskala/
Re: 0.9.0 expiration date: does not work [ In reply to ]
Bodo_Moeller at public
Jan 4, 1999, 9:35 PM
Post #6 of 15 (656 views)
Permalink
Werner Koch <wk@isil.d.shuttle.de>:
> Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de>:

>> Warnings are absolutely O.K., but it *should* be possible to use
>> expired expired (signing or decryption) secret keys. You might want,

> It is possible:
> gpg --edit-key your-key
>> expire
> and set a new expiration date.

That's a possibility, but it's somewhat awkward. Also, for decryption
keys that I keep just in order to be able to decrypt old stuff, I
would not really want to change the expiration date: The key _is_
expired, I have no intention to change that -- I simply want to use
it anyway.
I'd still vote for a new option that makes gpg ignore validity
periods.
Re: 0.9.0 expiration date: does not work [ In reply to ]
wk at isil
Jan 5, 1999, 12:47 AM
Post #7 of 15 (650 views)
Permalink
Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de> writes:

> That's a possibility, but it's somewhat awkward. Also, for decryption
> keys that I keep just in order to be able to decrypt old stuff, I

Okay, I can see this.
Re: 0.9.0 expiration date: does not work [ In reply to ]
roessler at guug
Jan 5, 1999, 2:01 AM
Post #8 of 15 (654 views)
Permalink
On Mon, Jan 04, 1999 at 09:35:00PM +0100, Bodo Moeller wrote:

> I'd still vote for a new option that makes gpg ignore validity
> periods.

ACK.

Additionally, gpg should only _warn_ if users try to use an expired
or revoked key for decrypting messages. It should print an _error_
(unless requested otherwise) if users try to use expired or revoked
keys for signing messages or encryption.

tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
Re: 0.9.0 expiration date: does not work [ In reply to ]
D.M.Pick at qmw
Jan 6, 1999, 4:02 AM
Post #9 of 15 (652 views)
Permalink
> Werner Koch <wk@isil.d.shuttle.de>:
> > Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de>:
>
> >> Warnings are absolutely O.K., but it *should* be possible to use
> >> expired expired (signing or decryption) secret keys. You might want,
>
> > It is possible:
> > gpg --edit-key your-key
> >> expire
> > and set a new expiration date.
>
> That's a possibility, but it's somewhat awkward. Also, for decryption
> keys that I keep just in order to be able to decrypt old stuff, I
> would not really want to change the expiration date: The key _is_
> expired, I have no intention to change that -- I simply want to use
> it anyway.
> I'd still vote for a new option that makes gpg ignore validity
> periods.

Hmm. Looking at RFC 2440 it appears that the key validity data appears
in the public key packet (or signature subpacket for V4). The secret
key data is the public key and its appendant data *plus* the secret
keys multi-precision integers and a checksum. With V4 and the validity
period data moving into signature sub-packets (possibly different in
different signatures to affect the validity of that signature) the
one that matters is the self-signature (I think). But this is
signing the public key data. I think it's arguable (and I would argue
myself) that uses like the one described should not be excluded by
expiry dates. A *warning* that the key is expired is a good idea, but
I don't think myself that you should even have to quote an optional
parameter to allow the expired secret key to be used *for decryption*.
Of course, it should not be possible to use it for generating new
signatures, &c. or to use the public data for excryption. However,
it *should* be possible to use the public data for signature
checking - for example to recheck the signature on an old EMail
message some time after it was received.

If people feel there should be a new option, perhaps what should be
added is an option to tell gpg to run in a mode where the operations
that I mentioned that should be allowed should be allowed *if they
would be allowed on a specific date given in the parameter*. Then
(for example) an EMail package could pass the date of the message
to gpg to instruct it to check validity as of the date of the
message rather than the clock time. Such an option should *not*
allow clock time to be overridden for operations like encryption
or signature generation.

What do other people think of this suggestion? Does it meet the
perceived needs?

--
David Pick
Re: 0.9.0 expiration date: does not work [ In reply to ]
david at hayes-family
Jan 6, 1999, 7:45 AM
Post #10 of 15 (648 views)
Permalink
On Wed, Jan 06, 1999 at 11:02:15AM +0000, David Pick wrote:
> If people feel there should be a new option, perhaps what should be
> added is an option to tell gpg to run in a mode where the operations
> that I mentioned that should be allowed should be allowed *if they
> would be allowed on a specific date given in the parameter*. Then
>
> What do other people think of this suggestion? Does it meet the
> perceived needs?

I would find that awkward. Specifying dates is a pain in the butt, and
parsing them with all their international variants isn't easy, either. I
think the best proposal so far is:

NO ERROR AT ALL for:

decrypting using an expired key.
verifying a signature of an expired key where the key had
not expired at the time the signature was created.

WARNING for:

verifying a signature when the key had already expired at
the time the signature was created.

ERROR (prohibited action) for:

encrypting to an expired key.
signing with an expired key.

--
David Hayes
david@hayes-family.org
Re: 0.9.0 expiration date: does not work [ In reply to ]
walberg at cig
Jan 6, 1999, 9:32 AM
Post #11 of 15 (651 views)
Permalink
my $0.02...

On 01/06/1999 08:45 -0600, David Hayes wrote:
>> NO ERROR AT ALL for:
>>
>> decrypting using an expired key.
>> verifying a signature of an expired key where the key had
>> not expired at the time the signature was created.
>>
>> WARNING for:
>>
>> verifying a signature when the key had already expired at
>> the time the signature was created.

**If** an option is added to force use of an expired key (for either encrypting
or signing) as has been suggested, there should be a WARNING when decrypting
something that was encrypted with an expired key. I personally don't think
the force option should be added, but the case has been made otherwise, and
if it is done, I think we need to add the warning here (if only for symmetry...).

>>
>> ERROR (prohibited action) for:
>>
>> encrypting to an expired key.
>> signing with an expired key.
>>
>> --
>> David Hayes
>> david@hayes-family.org
End of included message



--
+--------------------------------------+------------------------------------+
| Tim Walberg | Phone: (847) 632-3407 |
| Motorola CE/ITS | Pager: (800) SKY-TEL2 PIN:1384689 |
| 1475 W Shure Dr. IL75-2H14 | FAX: (847) 632-5769 |
| Arlington Heights, IL 60004 | |
+--------------------------------------+------------------------------------+
| http://www.cig.mot.com/~walberg | E-mail: walberg@cig.mot.com, |
| http://www.skytel.com/Paging (pager) | 1384689@skytel.com (pager) |
+--------------------------------------+------------------------------------+
Re: 0.9.0 expiration date: does not work [ In reply to ]
md at linux
Jan 6, 1999, 4:16 PM
Post #12 of 15 (650 views)
Permalink
On Jan 06, David Hayes <david@hayes-family.org> wrote:
>NO ERROR AT ALL for:
> verifying a signature of an expired key where the key had
> not expired at the time the signature was created.
The signer can easily alter the clock of his computer.

--
ciao,
Marco
Re: 0.9.0 expiration date: does not work [ In reply to ]
walberg at cig
Jan 7, 1999, 8:20 AM
Post #13 of 15 (651 views)
Permalink
On 01/07/1999 00:16 +0100, Marco d'Itri wrote:
>> On Jan 06, David Hayes <david@hayes-family.org> wrote:
>> >NO ERROR AT ALL for:
>> > verifying a signature of an expired key where the key had
>> > not expired at the time the signature was created.
>> The signer can easily alter the clock of his computer.
>>

Yes, but with that in mind, the whole idea of expiring keys and
trying to enforce or warn about their expiry is kinda moot anyway,
because if I'm gonna change my systems clock, I might as well change
it back to before the key even expired. I don't think that changing
the system time is really an eventuality we need to worry about -
possible (albeit infeasible) solutions would be to query a "known
true" clock on the net somewhere to determine the current time
(rather than calling time() et. al.), but even that can be rigged.

tw


--
+--------------------------------------+------------------------------------+
| Tim Walberg | Phone: (847) 632-3407 |
| Motorola CE/ITS | Pager: (800) SKY-TEL2 PIN:1384689 |
| 1475 W Shure Dr. IL75-2H14 | FAX: (847) 632-5769 |
| Arlington Heights, IL 60004 | |
+--------------------------------------+------------------------------------+
| http://www.cig.mot.com/~walberg | E-mail: walberg@cig.mot.com, |
| http://www.skytel.com/Paging (pager) | 1384689@skytel.com (pager) |
+--------------------------------------+------------------------------------+
Re: 0.9.0 expiration date: does not work [ In reply to ]
warner at lothar
Jan 8, 1999, 12:56 AM
Post #14 of 15 (651 views)
Permalink
walberg@cig.mot.com (Tim Walberg) writes:
>
> Yes, but with that in mind, the whole idea of expiring keys and
> trying to enforce or warn about their expiry is kinda moot anyway,
> because if I'm gonna change my systems clock, I might as well change
> it back to before the key even expired. I don't think that changing
> the system time is really an eventuality we need to worry about -
> possible (albeit infeasible) solutions would be to query a "known
> true" clock on the net somewhere to determine the current time
> (rather than calling time() et. al.), but even that can be rigged.

I'd think about it from the senders end: the purpose of having an expiration
date is to let the owner of a key stop worrying about compromise at some point
in the future. The safe assumption is that the moment the key expires, the
secret bits are flung out all over the net. Anything done with the secret
key after that point is not guaranteed to represent the real owner.

But if a key can expire, then it cannot be used for an archival (never
expiring) signature. If you read the message after the key has expired (which
means it might have been signed after the key expired, since you don't really
know when the signature was made), then the key should not be trusted without
a trusted timestamp. You reading the message (or the message being securely
timestamped) puts an upper bound on the time of the signature, and it's the
signing that has to happen before the key expires.

So I guess I'd print out two kinds of warnings when verifying signatures, one
if the key had already expired by the time the signature was created, and
another if the key has expired before "now" (when the verification is done).
The first tells you that the owner of the key was lazy and used a key that had
already expired (or they're having severe temporal disturbances). The second
tells you that you waited too long to verify the message and now you can't
really be sure that the signature is valid.

Clearly any private key operations (signing, decryption) should emit a
warning, if just to remind the user that they should have generated a new key
by now.

I'd warn on encryption too, suggesting that the user try to find a more
up-to-date key for that recipient.

-Brian
Re: 0.9.0 expiration date: does not work [ In reply to ]
david at hayes-family
Jan 8, 1999, 5:30 AM
Post #15 of 15 (651 views)
Permalink
On Thu, Jan 07, 1999 at 11:56:30PM -0800, Brian Warner wrote:
> in the future. The safe assumption is that the moment the key expires, the
> secret bits are flung out all over the net. Anything done with the secret
> key after that point is not guaranteed to represent the real owner.

[snip]

> So I guess I'd print out two kinds of warnings when verifying signatures, one
> if the key had already expired by the time the signature was created, and
> another if the key has expired before "now" (when the verification is done).

The first kind should be an ERROR, not a WARNING. That is, if the
signature claims to be made after the expiration of the key, then the
signature is INVALID. This should be distinguishable from invalid
because the signature doesn't have the correct checksum, in case the
user or another program wants to make the distinction. But it should be
an ERROR. After all, who can trust a signature made by a secret key that
was scattered across the net? :-)

> The first tells you that the owner of the key was lazy and used a key that had
> already expired (or they're having severe temporal disturbances).

This shouldn't be allowed to happen. "Original" use of a key (generating
a signature or encrypting to it) after the key's expiration date should
be a prohibited action.

> Clearly any private key operations (signing, decryption) should emit a
> warning, if just to remind the user that they should have generated a new key
> by now.
>
> I'd warn on encryption too, suggesting that the user try to find a more
> up-to-date key for that recipient.

People tend to ignore warnings. Programs used in a pipeline tend to
ignore them, too, looking for the more easily used exit status code.
These actions should be an ERROR. GPG should refuse to do wrong things.

If you really insist on the capability to do those things, I would be OK
with a command-line option to make those particular errors into warnings.
--
David Hayes
david@hayes-family.org

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal