RE: WGLC on DNSSEC bis document set

[Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>]

 [ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

Where protocol-04 says

   o  The resolver's notion of the current time MUST be less than or
      equal to the time listed in the RRSIG RR's Expiration field;

   o  The resolver's notion of the current time MUST be greater than or
      equal to the time listed in the RRSIG RR's Inception field;

perhaps "using serial number arithmetic" should be inserted into each
of these two points for clarity. This solves the problem you see.

Donald


-----Original Message-----
From: itojun@iijlab.net [mailto:itojun@iijlab.net] 
Sent: Thursday, January 22, 2004 9:04 PM
To: Eastlake III Donald-LDE008
Cc: namedroppers@ops.ietf.org; dnssec-editors@east.isi.edu
Subject: RE: WGLC on DNSSEC bis document set


> I think it is clear if you actually go look at the serial number arithmetic RFC;
> however it would probably be helpful to change
> 
>    Signature Expiration and Inception field values are in POSIX.1 time
>    format: a 32-bit unsigned number of seconds elapsed since 1 January
>    1970 00:00:00 UTC, ignoring leap seconds, in network byte order.
> 
> to
> 
>    Signature Expiration and Inception field values are POSIX.1 time
>    format modulo 2**32: the least significant 32-bits of the number of
>    seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap
>    seconds, in network byte order.
> 
> Since I believe that signature validity periods will rarely be even as
> long as one year, there is no need to waste bits by expanding these
> fields to 64 bits or to lose the one second resolution by scaling them.
> This is an instance where "serial number arithmetic" with a resolution
> of one second works well.

	based on what i get from protocol-04 page 28, expiration/inception
	field will be compared to wall clock of resolver, therefore DNSSEC
	baesd on the current packet format will not work after year 2106.
	so i think it necessary to address "after year 2106" issue by some way.
	there are multiple possibilities:
	- expand the field to 64bits
	- scaling (trade lifetime with resolution)
	- anything else?

itojun



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>