Subject: [DNSOP] The serial arithmetic involved in the comparison of the inception and expiration timestamp of RRSIG record

From: Joey Deng <[email-masked]>
Date: Thu, 03 Mar 2022 15:59:35 -0800

Hello,

[RFC 4034 3.1.5.  Signature Expiration and Inception Fields](https://datatracker.ietf.org/doc/html/rfc4034#section-3.1.5) says:

> 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

The description above seems to indicate that the two values in the RRSIG are **absolute** values, and they can be compared directly:

```c
// Example 1
# inception is smaller than expiration
if (inception < expiration) {
    // Do something.
}

# expiration is greater than inception
if (expiration > inception) {
    // Do something.
}

# Comapre the current time with the two timestamps.
const uint32_t now_uint32 = (uint32_t)time(NULL);
if (now_uint32 >= inception && now_uint32 <= expiration) {
    // RRSIG time valid
} else {
    // RRSIG time invalid
}
```

However, it also says:

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

The description above seems to indicate that the two values in the RRSIG are **relative** values, and they can only be compared with [Serial number arithmetic](https://datatracker.ietf.org/doc/html/rfc1982):

```c
// Example 2
# inception is smaller than expiration
if (((int32_t)(inception - expiration)) < 0) {
    // Do something.
}

# expiration is greater than inception
if (((int32_t)(expiration - inception)) > 0) {
    // Do something.
}

# Compare the current time with two timestamps.
const uint32_t now_uint32 = (uint32_t)time(NULL);
if (((int32_t)(now_uint32 - inception)) >= 0 && ((int32_t)(expiration - now_uint32)) >= 0) {
    // RRSIG time valid
} else {
    // RRSIG time invalid
}
```

## Questions

Therefore, my questions are:

1. Are the two descriptions in the RFC 4034 mentioned above contradictory with each other?
2. How to compare  `inception` and `expiration` correctly? (For example, if `example 2` I mentioned above is correct?)
3. If we have a value `inception` returned by `time(NULL)`, how can we get a value `expiration` that indicates the RRSIG will be valid for 68 years? (Of course the RRSIG should never be valid for a so long time)
   For example, something like `const uint32_t expiration = (uint32_t)((int32_t)inception + INT32_MAX)`?

Thanks.

--
Joey Deng

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 3 Mar 2022 19:15:35 -0500

> The description above seems to indicate that the two values in the RRSIG are **absolute** values, and they can be compared directly:

Almost but obviously 2**33 or more seconds since 1 Jan 1970 isn't
going to fit in 32 bits. It's an absolute value modulo 2**33.

> The description above seems to indicate that the two values in the RRSIG are **relative** values, and they can only be compared with [Serial number arithmetic](https://datatracker.ietf.org/doc/html…

Nope. see above.

> 1. Are the two descriptions in the RFC 4034 mentioned above contradictory with each other?

No.

> 2. How to compare  `inception` and `expiration` correctly? (For example, if `example 2` I mentioned above is correct?)

As specified in the referenced RFC 1982

>    For example, something like `const uint32_t expiration = (uint32_t)((int32_t)inception + INT32_MAX)`?

Ignoring leap years you just add 68*365*24*60*60 and throw away all
but the bottom 32 bits.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]