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