Mailing List Archive

On 26 Feb 2024, at 14:29, Jan Girlich <vollkorn@cryptobitch.de> wrote:
>
> I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and receive
> the following response:
>
> 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::'
>
> How is the timestamp '-62135596800' to be interpreted?

It would normally be interpreted as “seconds before the epoch”, but in this particular case the key is unparseable, so the number is meaningless. Keys can be unparseable for many reasons, but the most common one is the use of an obsolete primary key algorithm, such as RSA512 or Elgamal encrypt-and-sign.

A

Hi,

I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and receive
the following response:

'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::'

How is the timestamp '-62135596800' to be interpreted?

I looked up the RFC for the HKP and it states quite clearly, that this
field should be seconds since 01.01.1970:

https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp-00#section-5.2

Respectively:

https://datatracker.ietf.org/doc/html/rfc2440#section-3.5

How come the SKS server returns a negative timestamp then?

Cheers,
Jan


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi Andrew,

On Mon, 2024-02-26 at 17:14 +0000, Andrew Gallagher wrote:
> On 26 Feb 2024, at 14:29, Jan Girlich <vollkorn@cryptobitch.de>
> wrote:
> >
> > I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and
> > receive
> > the following response:
> >
> > 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::'
> >
> > How is the timestamp '-62135596800' to be interpreted?
>
> It would normally be interpreted as “seconds before the epoch”, but
> in this particular case the key is unparseable, so the number is
> meaningless. Keys can be unparseable for many reasons, but the most
> common one is the use of an obsolete primary key algorithm, such as
> RSA512 or Elgamal encrypt-and-sign.

thanks for this explanation. I know that this key worked fine from the
same keyserver before. Should I be worried about the integrity of the
web of trust with regard to corrupted keys? Or could it be that since
this key has been revoked that the keyserver is giving nonsensical
responses on purpose?

Cheers,
Jan

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 26 Feb 2024, at 17:42, Jan Girlich <vollkorn@cryptobitch.de> wrote:
>
> On Mon, 2024-02-26 at 17:14 +0000, Andrew Gallagher wrote:
>> On 26 Feb 2024, at 14:29, Jan Girlich <vollkorn@cryptobitch.de>
>> wrote:
>>>
>>> How is the timestamp '-62135596800' to be interpreted?
>>
>> It would normally be interpreted as “seconds before the epoch”, but
>> in this particular case the key is unparseable, so the number is
>> meaningless. Keys can be unparseable for many reasons, but the most
>> common one is the use of an obsolete primary key algorithm, such as
>> RSA512 or Elgamal encrypt-and-sign.
>
> thanks for this explanation. I know that this key worked fine from the
> same keyserver before.

This was most likely before it was migrated from sks-keyserver to hockeypuck, about three(?) years ago.

> Should I be worried about the integrity of the
> web of trust with regard to corrupted keys? Or could it be that since
> this key has been revoked that the keyserver is giving nonsensical
> responses on purpose?

So, for a bit of context, epoch minus 62135596800 is 1 Jan 0001. This is the default “zero time” in golang, meaning that any uninitialised timestamp variable will return this value. The expiry time for this key is uninitialised because there are no valid self-signatures over this key, which in turn is because it is an RSA1024 key, which is no longer supported by go-crypto/openpgp and therefore its signatures are unparseable by hockeypuck. In a sense, it is “not even revoked”. Any WoT certifications made by this key are no longer cryptographically sound and should not be relied upon.

A