# Bug decoding dates from DER-encoded streams

Robert Wille (RWILLE@novell.com)
Tue, 06 Apr 1999 13:03:12 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Sudheer Thakur: "missing default Sun Provider"
- Previous message: Robert Wille: "Importing self-signed certificates"
- Next in thread: Jan Luehe: "Re: Bug decoding dates from DER-encoded streams"

    Message-Id: <s70a49d4.053@prv-mail25.provo.novell.com>

    Date: Tue, 06 Apr 1999 13:03:12 -0600

    From: "Robert Wille" <RWILLE@novell.com>

    To: <java-security@java.sun.com>

    Subject: Bug decoding dates from DER-encoded streams

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 =3D Calendar.getInstance(TimeZone.getTimeZone("GMT"));
cal.set(year, month, day, hour, minute, second);
cal.set(Calendar.ERA, GregorianCalendar.AD);
Date readDate =3D 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.

- Next message: Sudheer Thakur: "missing default Sun Provider"
- Previous message: Robert Wille: "Importing self-signed certificates"
- Next in thread: Jan Luehe: "Re: Bug decoding dates from DER-encoded streams"