2004-06-15 Sebastien Pouliot <sebastien@ximian.com>

	* crypto: Updated status for beta 3. Removed stuff that is better
	documented in monodoc.

svn path=/trunk/mono/; revision=29645

2 files changed, 17 insertions, 66 deletions

diff --git a/web/ChangeLog b/web/ChangeLog
index 2af88e047fc..9ee97f4ba4b 100755
--- a/web/ChangeLog
+++ b/web/ChangeLog
@@ -1,3 +1,8 @@
+2004-06-15  Sebastien Pouliot  <sebastien@ximian.com>
+
+	* crypto: Updated status for beta 3. Removed stuff that is better 
+	documented in monodoc.
+
 2004-06-08  Duncan Mak  <duncan@ximian.com>
 
 	* download: Add MacOS X installer.
diff --git a/web/crypto b/web/crypto
index 76cf282143b..1b132dcdb40 100644
--- a/web/crypto
+++ b/web/crypto
@@ -11,41 +11,14 @@
 
 **** Status
 	<ul>
-		* All classes are present.
+		* All classes are present. Most of them have (minimal) 
+		  documentation in <b>monodoc</b>.
 
 		* Most classes have their unit tests. Some tests like <code>
 		  SymmetricAlgorithmTest</code> are generated by external 
 		  tools.
 	</ul>
 
-**** TODO
-	<ul>
-		* <code>PasswordDeriveBytes.CryptDeriveKey</code> is included 
-		  in MS BCL to provide compatibility with existing Windows 
-		  applications. The main problem is that the key derivation 
-		  algorithm can be different for every CSP (Crypto Service 
-		  Provider). However for compatibility we should provide an
-		  implementation compatible with the MS CSP (most likely used).
-	</ul>
-
-**** Notes
-	<ul>
-		* All cryptographic algorithms are entirely managed, including 
-		  classes named <code>*CryptoServiceProvider</code>, with the 
-		  exception of <code>RNGCryptoServiceProvider</code> for which 
-		  parts of the implementation resides in the runtime.
-
-		* There is a bug in the <code>PKCS1MaskGenerationMethod</code>
-		  class (in both framework 1.0 and 1.1). This means our 
-		  implementation isn't compatible with MS (but is compatible with
-		  PKCS#1 v.2.1). However we get OAEP padding for every platform!
-
-		* Look at assembly Mono.Security.Win32 if you require more
-		  compatiblity with the Microsoft implementation (like accessing
-		  a particuliar keypair container inside a specific CSP).
-	</ul>
-
-
 *** Namespace: <b>System.Security.Cryptography.X509Certificates</b>
 
 **** Status
@@ -66,25 +39,9 @@
 
 **** Notes
 	<ul>
-		* Except for their structure <b>there are no validation of the
-		  certificates</b> done by this class (this is by design and 
-		  isn't a restriction of Mono!). This means that certificate 
-		  signatures and validity dates are <b>never</b> checked 
-		  (except when used for Authenticode, i.e. 
-		  <code>CreateFromSignedFile</code>).
-
-		* The newer X509Certificate class included in Microsoft's Web 
-		  Service Enhancement (WSE) is a little better (as it includes 
-		  CryptoAPI's validation) when <code>IsCurrent</code> is called.
-		  See assembly <b>Microsoft.Web.Services</b> for more details.
-
 		* The class Mono.Security.X509.X509Certificate (in Mono.Security 
 		  assembly) is becoming a much better alternative - and will 
 		  continue to evolve to support the security tools.
-
-		* Microsoft implementation of <code>X509Certificate</code> is 
-		  done by using CryptoAPI (unmanaged code). Based on the 
-		  exceptions thrown, Authenticode(tm) support is done via COM.
 	</ul>
 
 <hr>
@@ -101,11 +58,11 @@
 		* We pass the fifteen tests from Merlin's xmldsig suite with
 		success. Which is funny because Microsoft fails in one case 
 		where both a X509Certificate and an X509CRL are present in
-		an X509Data.
-
-		* We now have a fully managed C14N implementation.
+		an X509Data. We also pass most Phaos tests.
 
-		* Most classes have their unit tests.
+		* Most classes have their unit tests. Some standalone tests 
+		are also in CVS to test C14N and both Merlin and Phaos test
+		suites.
 	</ul>
 
 <hr>
@@ -139,13 +96,10 @@
 		Carlos Guzman Alvarez.
 		* Ntlm: NTLM authentication (used for HTTP and SQL Server).
 	</ul>
-*** Namespace: Mono.Security.X509
+*** Namespace: Mono.Security.X509.*
 	<ul>
 		* X.509 structures (certificate, CRL...) building and decoding.
 		* PKCS#12 decoding and encoding.
-	</ul>
-*** Namespace: Mono.Security.X509.Extensions
-	<ul>
 		* X.509 extensions (from public X.509 to private PKIX, Netsapce, 
 		  Microsoft, Entrust...).
 	</ul>
@@ -271,19 +225,15 @@
 
 *** Notes
 	<ul>
-		* Microsoft has <a href="http://microsoft.com/downloads/details.aspx?FamilyId=21FB9B9A-C5F6-4C95-87B7-FC7AB49B3EDD&displaylang=en">released</a>
-		a technical preview of WSE 2. <b>Note that WSDK (the technical 
-		preview of WSE) had A LOT of changes before it's initial 
-		release!</b>
+		* Microsoft has released WSE 2.
 	</ul>
 
 <hr>
 ** Tools
 
 	There are many tools in the .NET framework that indirectly interacts 
-	with some cryptographic classes. Mono will eventually need these tools.
-	Unless noted the tools should work on any CLR (tested with both Mono 
-	and Microsoft).
+	with some cryptographic classes. Unless noted the tools should work on
+	any CLR (tested with both Mono and Microsoft).
 
 **** Status
 
@@ -304,7 +254,7 @@
 		* <code>sn</code> is a clone of the <code>sn</code> to manage
 		  strongnames. Current version can create, convert, sign and
 		  verify strongnames signatures. Some configuration options 
-		  are still missing.
+		  are still missing, some will only works with Mono.
 
 		* <code>signcode</code> and <code>chktrust</code> for signing 
 		  and validating Authenticode(tm) signatures on assemblies (or 
@@ -327,10 +277,6 @@
 		  <code>System.Windows.Forms</code> (right now only working on 
 		  Windows), while <code>gcertview</code> is the same viewer 
 		  implemented for GTK# (working on both Windows and Linux).
-
-		* <code>monosn</code> is a clone of the <code>sn</code> to manage
-		  strongnames. This tools is part of the runtime (not the class
-		  library) and as such is written in C and won't run without Mono.
 	</ul>
 
 
@@ -381,4 +327,4 @@
 		  <b>monodoc</b>.
 	</ul>
 <hr>
-Last reviewed: March 20, 2004 (mono 0.31)
+Last reviewed: June 15, 2004 (mono beta 3)