**** TODO
<ul>
+ * The current implementation of <code>CryptoStream</code> is
+ very limited and contain known bugs (<a
+ href="http://bugzilla.ximian.com/show_bug.cgi?id=40689">
+ 40689</a>). The class need to be re-designed.
+
* Support for adding/modifying OID using the
<code>machine.config</code> configuration file (algorithms
are done).
* RNGCryptoServiceProvider is currently only working on Linux.
The current implementation reside in Mono's runtime and use
the <code>/dev/[u]random</code> device (which do not exists
- under Windows). A Windows alternative is in the work (see
- Mono.Security.Win32 assembly section).
+ under Windows). A Windows specific alternative is available
+ using the Mono.Security.Win32 assembly.
* Keypair persistance for RSA and DSA. This persistance must
somehow be linked with X509 certificate stores (in planning).
* <code>PasswordDeriveBytes.CryptDeriveKey</code> is included
- in the BCL to provide compatibility with existing Windows
+ 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
classes named <code>*CryptoServiceProvider</code>, with the
exception of <code>RNGCryptoServiceProvider</code> (which
resides in the runtime).
+
+ * 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>
**** Status
<ul>
* X.509 certificates are parsed using 100% managed code
- (using an internal ASN.1 class).
+ (using the Mono.Security.ASN1 class).
* Software Publisher Certificates (SPC) used by Authenticode
(tm) to sign assemblies are supported (extraction from PE
- files) but <b>not</b> validated.
+ files) but <b>not yet</b> validated.
- * Tests are generated from a set of existing certificates
+ * Unit tests are generated from a set of existing certificates
(about a dozen) each having different properties. Another
set of certificates (more than 300) are used for a more
- complete test (but isn't part of the test suite for size
- and time consideration).
+ complete test (but isn't part of the standard test suite for
+ size and time consideration, i.e. a 3.5Mb C# source file).
</ul>
**** TODO
**** Notes
<ul>
- * <b>There's no validation of the certificates</b> done in this
- class (this 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.
+ * 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). From the exceptions
+ done by using CryptoAPI (unmanaged code). From the exceptions
thrown Authenticode(tm) support is done via COM.
</ul>
**** Status
<ul>
- * All classes are present but some (Transforms) are only
+ * All classes are present but some (most Transforms) are only
stubbed.
* Most classes have their unit tests.
-
- * This assembly is present in CVS but only available when
- building using NAnt (i.e. makefile are missing).
</ul>
**** TODO
signing (not because the transforms works). In the short
term <code>libxml2</code> could be used to provide C14N, but
in the long term a fully managed class would be much better.
+ </ul>
+
+<hr>
+** Assembly: Mono.Security
- * Makefile for building under non-Windows operating systems.
+ <b>Rational</b>
+ This assembly provides the missing pieces to .NET security. On Windows
+ CryptoAPI is often used to provide much needed functionalities (like
+ some cryptographic algorithms, code signing, X.509 certificates).
+
+*** Namespace: Mono.Security
+ <ul>
+ * Structures (ASN1, PKCS7) and primitives (PKCS1).
+ </ul>
+*** Namespace: Mono.Security.Authenticode
+ <ul>
+ * Code signing and verification.
+ * Support for SPC files and PVK files.
+ </ul>
+*** Namespace: Mono.Security.Cryptography
+ <ul>
+ * Additional algorithms: MD2, ARCFOUR (required for SSL)
+ * Convertion helpers
+ </ul>
+*** Namespace: Mono.Security.X509
+ <ul>
+ * X.509 certificate building and decoding.
+ </ul>
+*** Namespace: Mono.Security.X509.Extensions
+ <ul>
+ * X.509 extensions (from X.509, PKIX, Netsapce, Microsoft,
+ Entrust...).
+ </ul>
+
+**** Status
+ <ul>
+ * Some part of the work has not yet been commited (cleaning up).
+
+ * A big part of this assembly is also included inside Mono's
+ corlib. The class are duplicated in this assembly so the
+ functionalities can be used without a dependency on Mono's
+ corlib (which depends on Mono's runtime).
+
+ * Unit test coverage isn't (yet) complete.
</ul>
<hr>
** Assembly: Mono.Security.Win32
+ <b>Rational</b>
This assembly goal is to provide maximum compatibility with CryptoAPI
to application running with Mono's runtime on the Windows operating
system.
</code> configuration file (and then only if this increased
compatibility is required by an application).
+ See the file <code>/mcs/class/Mono.Security.Win32/README</code> for
+ complete instructions.
+
*** Namespace: Mono.Security.Cryptography
**** Status
<ul>
- * A RNGCryptoServiceProvider built on top of CryptoAPI.
+ * A RNGCryptoServiceProvider built on top of CryptoAPI. This
+ allows Windows users to get around the limitation of the
+ runtime RNG (which requires <code>/dev/[u]random/</code>).
* Wrapper classes for unmanaged versions of hash algorithms:
- MD2, MD4, MD5 and SHA1 are supported.
-
- * Not (yet) commited in CVS - i'm still playing with the base
- classes so I can easily add other CryptoAPI-based algorithms.
+ MD2, MD4, MD5 and SHA1 are supported. <b>note</b>: some
+ algorithms shouldn't be used in new design (MD4 is broken and
+ MD2 isn't considered safe). They are included to preserve
+ interoperability with older applications (e.g. some old, but
+ still valid, X.509 certificates use MD2).
</ul>
**** TODO
* Wrapper classes for unmanaged versions of symmetric
encryption algorithms (like DES, TripleDES, RC2 and others
present in default CSP).
+
* Wrapper classes for unmanaged versions of asymmetric
algorithms (like DSA and RSA) which persist their keypair
into the specified CSP.
</ul>
+**** Ideas
+ <ul>
+ * Similar assembly could be created for <a href="http://www.openssl.org">
+ OpenSSL</a>, NSS, crypto++, cryptlib ... for improved
+ performance and/or HSM support under Linux.
+ </ul>
<hr>
** Assembly: Microsoft.Web.Services
Development Kit (WSDK) in it's beta days, is an add-on the .NET
framework that implements WS-Security (and other WS-* specifications).
It also includes improved support for XML Signature (replacing and/or
- extending <code>System.Security.Cryptography.Xml</code>) and X509
- certificates.
+ extending <code>System.Security.Cryptography.Xml</code>) and X.509
+ certificates classes.
- Note: WSE is distributed as an add-on because the WS-Security
- specification isn't yet completed by
- <a href="http://www.oasis-open.org/committees/wss/">OASIS</a>.
+ Note: WSE is distributed as an add-on because some specifications,
+ like WS-Security, aren't yet completed by
+ <a href="http://www.oasis-open.org/committees/wss/">OASIS</a> or
+ other committees.
- <b>There are some licensing issues to consider before stating to
+ <b>[*] There are some licensing issues to consider before stating to
implement WS-Security. All contributors must sign an agreement with
Microsoft before commiting anything related to WS-Security into CVS.
</b>
-*** Namespace: Microsoft.Web.Services.Security
+*** Namespace: Microsoft.Web.Services.Security [*]
+*** Namespace: Microsoft.Web.Services.Timestamp [*]
**** Status
<ul>
- * Nothing (yet) commited in CVS.
+ * Nothing (yet) commited in CVS <b>[*]</b>.
</ul>
*** Namespace: Microsoft.Web.Services.Security.X509
**** Status
<ul>
- * Nothing (yet) commited in CVS.
+ * Nothing (yet) commited in CVS. However the classes in this
+ namespace are outside WS-Security scope. So development, for
+ those, could be done without signing any agreements.
</ul>
**** TODO
</ul>
<hr>
-** Other stuff
-
- There are other, not so visible, uses of cryptography both inside and
- outside the class library - such as:
-
- <ul>
- * SSL/TLS for secure communication (investigation under way).
-
- * Assembly signing (and verification) using StrongNames.
-
- * Assembly signing (and verification) using Authenticode(tm).
- </ul>
-
-
-*** Tools
+** Tools
There are many tools in the .NET framework that indirectly interacts
with some cryptographic classes. Mono will eventually need these tools.
* <code>cert2spc</code> is a tool to transform multiple X.509
certificates and CRLs into a Software Publisher Certificate
(SPC) file - which is a long name for a simple PKCS#7 file.
+
+ * <code>makecert</code> to create X.509 test certificates that
+ can be used (once transformed in SPC) to sign assemblies.
</ul>
**** TODO
for signing and validating Authenticode(tm) signatures on
assemblies (or any PE file).
- * <code>makecert</code> to create X.509 test certificates that
- can be used (once transformed in SPC) to sign assemblies.
-
* Other tools like a, GUI-based, certificate manager...
</ul>
Note that many of the tools requires the class library and/or the
- runtime to be ready for them.
+ runtime to be ready for them. E.g. StrongName and Authenticode signatures
+ tools are of limited use until supported by the runtime.
+
+<hr>
+** Other stuff
+
+ <ul>
+ * SSL/TLS for secure communication (a prototype is under way).
+ Some work is already visible in Mono.Security assembly (e.g.
+ RC4).
+ </ul>
+
<hr>
** How to Help
Add missing unit tests to classes or methods.
- Write some documentation on the cryptographic classes for MonkeyGuide
- (as I'm not a good writer, at least in English, but you must be a good
- reader if you got to this part).
+ Write some documentation on the cryptographic classes for the
+ <a href="http://go-mono.com/tutorial/html/en/index.html">Mono
+ Handbook</a> as I'm not a very good writer (at least in English).
Optimization can also be done on algorithms as crypto is never fast
enough. Just be sure to test every optimization (using the unit test)
informations about the status of the cryptographic classes.
<hr>
-Last reviewed: February 4, 2003 (post mono 0.19)
+Last reviewed: April 7, 2003 (post mono 0.23)
projects / mono.git / blobdiff