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 ver
In message , "
Paul B. Henson" writes:
> On Wed, 28 Apr 2010, Mark Andrews wrote:
>
> > The .private timestamps are in UTC and that is what is used for key
> > management. The .key values are just comments. You should be able to
> > work out my current offset from UTC.
> >
> > % grep Created Kl
On Wed, 28 Apr 2010, Mark Andrews wrote:
> The .private timestamps are in UTC and that is what is used for key
> management. The .key values are just comments. You should be able to
> work out my current offset from UTC.
>
> % grep Created Kl.+005+59421.*
> Kl.+005+59421.key:; Created: T
In message , "
Paul B. Henson" writes:
>
> I've been testing dnssec-keygen and the "smart signing" mode of
> dnssec-signzone and have run into some timezone confusion; I'm not sure if
> it's expected behavior or a bug. I searched around a bit and didn't find
> anything relevant, apologies in adva
I've been testing dnssec-keygen and the "smart signing" mode of
dnssec-signzone and have run into some timezone confusion; I'm not sure if
it's expected behavior or a bug. I searched around a bit and didn't find
anything relevant, apologies in advance if I missed a FAQ.
If I create a new key leav
5 matches
Mail list logo