401945 - certutil should show validity period timezone

Status: NEW

(NSS :: Tools, enhancement, P5)

Description

[Bob Lord]

The certutil tool pretty prints validity periods like this:

        Validity:
            Not Before: Wed Oct 31 20:55:05 2007
            Not After : Thu Jan 31 20:55:05 2008

The problem is that this timezone is (I think) in GMT, but it does not say so.  This is a problem for users who have been confused when trying to correlate other log files with a certificate's validity period.

I propose that we add the string "(GMT)" after the date like this to remove any confusion:
            Not Before: Wed Oct 31 20:55:05 2007 (GMT)

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Several thoughts on this RFE.

#1.  IIRC, we convert cert timestamps into PRTime, and then display it 
using an NSPR time display function which, IIRC, displays it in the LOCAL
time zone, whatever that is.  

If my recollection on that point is correct, then perhaps we should display
"Local Time" rather than GMT.

#2.  There recently was an enhancement to NSPR to give it the ability to 
keep time zone information.  This was done so that time stamps in TBird 
mail message headers could be displayed with time zones, IIRC.  

Perhaps that feature should be used here also, so that the time zone info
embedded in the UTCTime or GeneralizedTime string can be carried through
and displayed in the output.  (No way to carry it in a PRTime, though. :-/ )

Comment 2

[Bob Lord]

I don't have a preference one way or another as to which timezone we show (local vs. GMT), but we should say which one it is so people who use the tools to troubleshoot are not confused.

Local time might be a *little* better for those people who are comparing cert expiration times with their server logs since those logs tend to use local timestamps. That way they don't have to do the time conversions.

Comment 3

[bill]

Putting my implementer's hat on:
I'd prefer certutil (and related tools) to display time in GMT. Here's a recent example: While trying to deploy a root CA, I did my development and testing in the PST timezone. The audited ceremony was in the MST timezone, and the certutil output didn't specify the timezone.

Explaining to the auditors who were breathing over your shoulder that the expected output was correct (mod implicit timezone differences) was overly complex. The same was true for our documentation efforts; inconsistent timezones was more error-prone to document.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The relevant code is 
http://lxr.mozilla.org/mozilla/source/security/nss/cmd/lib/secutil.c#1006

1006 static void
1007 secu_PrintTime(FILE *out, int64 time, char *m, int level)
1008 {
1009     PRExplodedTime printableTime; 
1010     char *timeString;
1011 
1012     /* Convert to local time */
1013     PR_ExplodeTime(time, PR_GMTParameters, &printableTime);

The comment is wrong (and should be corrected).  It is displayed in GMT. 

As seen at 
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/secutil.c#1044
and
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/secutil.c#1063
we convert the UTCTime or GeneralizedTime string to a PRTime, which loses
the time zone info (PRTime is always in GMT) and then we print it as a GMT.

I wish that we had an alternative form of the functions 
SECU_PrintUTCTime and SECU_PrintGeneralizedTime 
that also extracted the time zone info and printed it.
But for now, clearly, adding "GMT" to the printed output is the shortest 
solution.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

While we're tweaking the date/time display format, any thoughts about 
the odd format we use, e.g. 
   Wed Oct 31 20:55:05 2007            which is
   DDD MMM dd hh:mm:ss YYYY

Here are some alternative formats, any one of which is more appealing to me.

1) Wed Oct 31 2007 20:55:05 
   DDD MMM dd YYYY hh:mm:ss 

2) Wed 2007 Oct 31 20:55:05 
   DDD YYYY MMM dd hh:mm:ss 

3) 2007 Oct 31 20:55:05 (Wed)
   YYYY MMM dd hh:mm:ss (DDD)

Thoughts?

Comment 6

[Bob Lord]

Does anyone write scripts to parse the output of certutil?  If so, changing the date format might break those scripts.

If that's not an issue, then #3 has the desirable quality of being sorted from year to second, and the day of the week (which I don't think I've ever used) is at the end.

Comment 7

[bill]

I'd say it's likely that that customers have written scripts to automatically parse certutil's output. I know my team does with similar tools. It's highly likely that any change we make to certutil will break those scripts.

Since we're contemplating a change (to add GMT), we may as well take the opportunity to make the output more sane as Nelson has observed. Option 3 seems more "correct" but option 1 reads more easily to me. Regardless, both examples should have the string " GMT" following the time.

Comment 8

[Robert Relyea]

Marking P1 since it's a customer escalation.