dnssec-keygen & dnssec-signzone "smart signing" vs time zones

[Paul B. Henson]

On Wed, 28 Apr 2010, Mark Andrews wrote:

> Would something like this be better? Do you need a UTC after the
> timestamp.
[...]
> ; Created: 20100429025050 (Thu Apr 29 12:50:50 2010)

Even though it's just a comment, it would be nice for it not to be
ambiguous. As a comment, the raw value isn't very parsable, the descriptive
version itself would probably be fine if it was either always in UTC and
included a UTC suffix to make it obvious, or if relativized to the
localtime included that timezone as a suffix.

> Note: now + delta is timezone agnostic.

Yes, but I was tentively planning on rotating zone keys once a month, and
to simplify that making the 1st of the month the cutoff. It's easy to say
"the 1st of next month" in an absolute fashion, but in a delta fashion
you'd need to worry about how many days each month has. There's probably a
better implentation anyway, we're still in the early prototyping phase.

> From dnssec-signzone
[...]
>            20000530144500 denotes 14:45:00 UTC on May 30th, 2000.

Perhaps this same example/clarification could be added to the man pages for
dnssec-keygen and dnssec-settime under the "TIMING OPTIONS" section? That's
the documentation I was reviewing while looking into this.

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768