Message-Id: <199904070105.SAA07594@laguna.eng.sun.com>
Date: Tue, 6 Apr 1999 18:05:27 -0700 (PDT)
From: Jan Luehe <luehe@laguna.eng.sun.com>
Subject: Re: Bug decoding dates from DER-encoded streams
To: java-security@java.sun.com, RWILLE@novell.com
Robert:
Thanks for reporting this!
I have been able to verify it.
We will have a fix for it in the Kestrel (JDK 1.3)
release.
Thanks,
Jan
> There is a bug when dates are read from DER encoded streams. If you look at
sun/security/util/DerInputStream.java from JDK 1.2 at lines 446 through 449,
you'll find the following lines of code:
>
> Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
> cal.set(year, month, day, hour, minute, second);
> cal.set(Calendar.ERA, GregorianCalendar.AD);
> Date readDate = cal.getTime();
>
> The first line initializes the calendar with the current time. The second and
third lines set a new date and time in the calendar. However, the milliseconds
field is left unchanged (i.e. the current milliseconds is left). So, basically,
you end up with the correct date plus up to 1000 milliseconds. If I read in two
certificates, each with the same validity dates and compare the validity dates
to ensure that the subordinate certificate is not valid before or after its
superior certificate, the comparison will fail because of the current
milliseconds being left in the date.
>
> Read a certificate and print out the validity dates (including milliseconds).
Do this over and over again and you will see the validity dates changing.
>
>