[db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects

Hi

Just playing devil's advocate to be sure :) 

cheersdenisco-chair DB-WG

      From: Edward Shryane <eshryane at ripe.net>
 To: Sandra Murphy <sandy at tislabs.com> 
Cc: denis walker <ripedenis at yahoo.co.uk>; db-wg <db-wg at ripe.net>
 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 <sandy at tislabs.com> 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 <db-wg at ripe.net> wrote:
>> 
>> Hi Denis,
>> 
>>> On 11 Feb 2019, at 16:53, denis walker <ripedenis at yahoo.co.uk> 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
>> 
> 


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20190211/881ba74c/attachment.html>