Re: [dnsext] SIG inception/expiration

On 2 Jan 2012, at 14:03, Miek Gieben wrote:

> [ Quoting <marka@isc.org> at 00:52 on Jan  3 in "Re: [dnsext] SIG inc..." ]
>> 
>> In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes:
>>> Hello list,
>>> 
>>> A recent dnssec-deployment discussion led to the question on why the
>>> expiration/inception time in the RRSIG are in the "wrong" order.
>> 
>> Actually the order makes lots of sense.  Expiration time is almost
>> always the critical value in a signature.  Inception time is almost
>> always in the past.  One could completely remove inception time
>> and still have secure signatures.
> 
> But was this the original reason to change the order?
> 
> And someone, not trained in the Jedi ways of DNSSEC, will look at an RRSIG and
> assume the first time stamp is the inception and the second one is expiration.

That is true. I have often had to double check this order - I just remember that there is something funny with it now and always double check. 

I had always thought that, as Mark said, inception makes no difference to security, and that perhaps there is no operational reason to use any value other than 0 for the inception. Setting it to zero would at least stop it standing out in the RRSIG. However, a quick re-read of 4034 3.1.5 reminds me that 

  The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.  The longest interval that can be expressed by this
   format without wrapping is approximately 136 years.  An RRSIG RR can
   have an Expiration field value that is numerically smaller than the
   Inception field value if the expiration field value is near the
   32-bit wrap-around point or if the signature is long lived.  Because
   of this, all comparisons involving these fields MUST use "Serial
   number arithmetic", as defined in [RFC1982].  As a direct
   consequence, the values contained in these fields cannot refer to
   dates more than 68 years in either the past or the future.

so I guess it does need to be set to something reasonable if you use very long validity periods or we are nearing 2106. However, it makes me wonder if there is ever a reason to compare them, and if serial number arithmatic is actually meaningful here? 

John

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext