GeneralizedTime decoder do not allow for leap seconds

NEW
Unassigned

Status

NSS
Libraries
P3
normal
15 years ago
8 years ago

People

(Reporter: Julien Pierre, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
In the case of leap seconds, seconds in UTCTime and GeneralizedTime can be 0 to
60, not 0 to 59, as enforced by our decoders. 
This is only valid if the time is 23:59:60 and at certain designated designed dates.
We should fix this in DER_AsciiToTime and DER_GeneralizedTimeToTime to be
allowed. Currently we consider seconds greater than 59 to be errors.
All leap seconds happen on the last day of the year, IINM so we should only 
allow them if mmddhhmm  is 12312359, I think.  (Maybe hour can be another 
value due to timezones, so maybe 1231xx59 is enough.)  

Comment 2

15 years ago
Leap seconds can occur twice a year and can be either sign. See 
<http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat>.

Comment 3

15 years ago
Sorry about the spam but see also
<http://hpiers.obspm.fr/eoppc/bul/bulc/BULLETINC.GUIDE>.
QA Contact: bishakhabanerjee → jason.m.reid
(Reporter)

Comment 4

13 years ago
In X.680, UTCTime does not support leap seconds. However, ISO 8601, which GeneralizedTime is based on, does . So we need to allow for a value of seconds of 60 for GeneralizedTime only.
Summary: UTCTime/GeneralizedTime decoders do not allow for leap seconds → GeneralizedTime decoder do not allow for leap seconds
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.