Hi
Just playing devil's advocate to be sure :)
cheersdenisco-chair DB-WG
From: Edward Shryane <[email protected]>
To: Sandra Murphy <[email protected]>
Cc: denis walker <[email protected]>; db-wg <[email protected]>
Sent: Monday, 11 February 2019, 19:56
Subject: Re: [db-wg] Proposal for restricting authentication concerning use of
revoked and expired GPG ID's in key-cert objects
Hi Sandy,
according to the OpenPGP Message Format RFC
(https://tools.ietf.org/html/rfc4880), the signature creation time is in UTC.
3.5. Time Fields
A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC.
5.2.3.4. Signature Creation Time
(4-octet time field)
The time the signature was made.
Regards
Ed
> On 11 Feb 2019, at 19:29, Sandra Murphy <[email protected]> wrote:
>
> I’m surprised at the question. I don’t know PGP/GPG all that well, but I
> checked and the IETF standard for X-509 certificates (RFC5280) requires CAs
> to use UTC in the signature time fields, and CMS (RFC5682) requires UTC in
> the SigningTime (in both cases, up to the year 2049).
>
> Does this become an issue because the signatures in the RIPE database are
> doing something different?
>
> —Sandy
>
>
>> On Feb 11, 2019, at 11:41 AM, Edward Shryane via db-wg <[email protected]>
>> wrote:
>>
>> Hi Denis,
>>
>>> On 11 Feb 2019, at 16:53, denis walker <[email protected]> wrote:
>>>
>>> Hi Ed
>>>
>>> Thanks for following up on this. Just one question, have you taken into
>>> account time zones? If an update is signed now in Dubai it is 19:51. If the
>>> update is processed on Amsterdam time, it is 16:51. Will this update fail
>>> because it is 3 hours in the future?
>>>
>>> cheers
>>> denis
>>> co-chair DB-WG
>>>
>>
>> Good question. We rely on the Bouncy Castle cryptography library to provide
>> the signing time for the message, and it does appear to take the timezone
>> into account.
>>
>> I tested by signing a message inside a virtual machine set to a different
>> timezone (EST), and the signature creation time was correctly mapped to the
>> local timezone (within a minute rather than hours).
>>
>> The signed updates in production appear to confirm this - only 24 messages
>> were more than 1 hour old, out of 118,183 (from October to December 2018),
>> and none of these appeared to be offset by a multiple of hours.
>>
>> Regards
>> Ed
>>
>
