[Mono-bugs] [Bug 75987][Nor] Changed - CRL ThisUpdate & NextUpdate UTC conversion

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by sebastien at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=75987

--- shadow/75987	2005-09-05 13:30:07.000000000 -0400
+++ shadow/75987.tmp.32416	2005-09-24 11:36:39.000000000 -0400
@@ -1,13 +1,13 @@
 Bug#: 75987
 Product: Mono: Class Libraries
 Version: 1.1
 OS: unknown
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: NOTABUG
 Severity: Unknown
 Priority: Normal
 Component: Mono.Security
 AssignedTo: sebastien at ximian.com                            
 ReportedBy: dgranath at gmail.com               
 QAContact: mono-bugs at ximian.com
@@ -22,6 +22,121 @@
   nextUpdate = ASN1Convert.ToDateTime (next);
 
 should be: 
 
   thisUpdate = ASN1Convert.ToDateTime (toBeSigned [n++]).ToUniversalTime();
   nextUpdate = ASN1Convert.ToDateTime (next).ToUniversalTime();
+
+------- Additional Comments From sebastien at ximian.com  2005-09-24 11:36 -------
+Time is a complex issue... let's see...
+
+I have a CRL named oces.crl, using an ASN.1 viewer we can see this (in
+universal time).
+
+0079 17 0013 : . . UTCTime '050310124543Z'
+0094 17 0013 : . . UTCTime '050311014543Z'
+
+With a small program we can show how the X.509 CRL reports the time...
+
+using System;
+using Mono.Security.X509;
+
+class Program {
+
+	static void Main (string[] args)
+	{
+		X509Crl crl = X509Crl.CreateFromFile (args [0]);
+		Console.WriteLine ("ThisUpdate {0}", crl.ThisUpdate);
+		Console.WriteLine ("NextUpdate {0}", crl.NextUpdate);
+	}
+}
+
+Compile...
+
+mcs 75987.cs -r:Mono.Security.dll
+
+... and execute ...
+
+mono 75987.exe ~/oces.crl
+ThisUpdate 3/10/2005 7:45:43 AM
+NextUpdate 3/10/2005 8:45:43 PM
+
+... so we see that the class returns the "local date/time" (and not
+the universal time) - but is it OK ?
+
+Let's see how we (Mono.Security) handle certificates. I have a
+certificate with this dates...
+
+0116 17 0013 : . . . UTCTime '980822164151Z'
+0131 17 0013 : . . . UTCTime '180822164151Z'
+
+a similar sample shows the dates...
+
+using System;
+using System.IO;
+using Mono.Security.X509;
+
+class Program {
+
+	static void Main (string[] args)
+	{
+		using (FileStream fs = File.OpenRead (args [0])) {
+			byte[] data = new byte [fs.Length];
+			fs.Read (data, 0, data.Length);
+			X509Certificate cert = new X509Certificate (data);
+			Console.WriteLine ("ValidFrom {0}", cert.ValidFrom);
+			Console.WriteLine ("ValidUntil {0}", cert.ValidUntil);
+		}
+	}
+}
+
+... compile, execute...
+
+ValidFrom 8/22/1998 12:41:51 PM
+ValidUntil 8/22/2018 12:41:51 PM
+
+... again local time. But is this compatible with MS implementation of
+X509Certificate ?
+
+Yet another program to compile and execute...
+
+using System;
+using System.IO;
+using System.Security.Cryptography.X509Certificates;
+
+class Program {
+
+	static void Main (string[] args)
+	{
+		X509Certificate cert = X509Certificate.CreateFromCertFile (args [0]);
+		Console.WriteLine ("ValidFrom {0}", cert.GetEffectiveDateString ());
+		Console.WriteLine ("ValidUntil {0}", cert.GetExpirationDateString ());
+	}
+}
+
+... with surprising results ... that's not local time and it's not the
+universal time either ?
+
+ValidFrom 8/22/1998 8:41:51 AM
+ValidUntil 8/22/2018 8:41:51 AM
+
+is there a bug in Mono ? let's run the same thing under MS runtime.
+
+ValidFrom 8/22/1998 8:41:51 AM
+ValidUntil 8/22/2018 8:41:51 AM
+
+same results ? but what is it ?
+
+Answer (from Microsoft) is that 1.0/1.1 is buggy and return the time
+for the Seattle (guess why ;-) time zone. Pretty useless.
+
+So recompile (under Windows) the same sample with Fx 2.0 and you'll get...
+
+ValidFrom 8/22/1998 12:41:51 PM
+ValidUntil 8/22/2018 12:41:51 PM
+
+... local time! and under Mono 2.0 (gmcs) ? same bad result (I've not
+fixed it yet ;-).
+
+Conclusion: when the time is "usable" it's a local time
+
+Note: I've not tried X509Certificate2