<ul>
* Every classes are present.
- * Most classes have their unit tests.
+ * Most classes have their unit tests. Some tests like <code>
+ SymmetricAlgorithmTest</code> are generated by an external
+ tool.
</ul>
**** TODO
<ul>
- * Support for adding/modifying algorithms and OID using the
- <code>machine.config</code> configuration file (in progress).
+ * 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...
+ under Windows). A Windows alternative is in the work (see
+ Mono.Security.Win32 assembly section).
* Keypair persistance for RSA and DSA. This persistance must
somehow be linked with X509 certificate stores (in planning).
- * <code>MACTripleDES</code> is not functionnal. There are many
- differents and conflicting standards about how to do MAC
- (NIST has two, ANSI has one, maybe the framework is using
- yet another). We just have to figure out which one it is.
-
- * <code>PasswordDeriveBytes</code> is currently limited to
- generating keys with the maximum length equals to the hash
- output (as specified in PKCS #5). However the framework
- implementation allows for longer keys to be generated. Also
- the algorithms used by CryptDeriveKey (used by Windows
- applications) are unknown.
+ * <code>PasswordDeriveBytes.CryptDeriveKey</code> is included
+ in the 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).
* Analyse the current coverage of the unit tests on the
cryptographic classes and complete the unit tests.
**** Status
<ul>
- * X.509 certificates are parsed using 100% managed code.
+ * X.509 certificates are parsed using 100% managed code
+ (using an internal ASN.1 class).
* Software Publisher Certificates (SPC) used by Authenticode
(tm) to sign assemblies are supported (extraction from PE
* Authenticode(tm) support is incomplete. We can extract the
certificates from PE files but cannot validate the signature
nor the certificate chain (and we're still missing some trust
- anchors).
+ anchors). See Tools section for more information.
- * Integration with CryptoAPI isn't possible as long as the
- <code>X509Certificate(IntPtr)</code> constructor isn't
- completed.
+ * Integration with CryptoAPI (on Windows) isn't possible as
+ long as the <code>X509Certificate(IntPtr)</code> constructor
+ isn't completed.
</ul>
**** 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 never checked!
+ 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
- validation).
+ CryptoAPI's validation) when <code>IsCurrent</code> is called.
* Microsoft implementation of <code>X509Certificate</code> is
- done by using CryptoAPI. From the exceptions thrown
- Authenticode(tm) support is done via COM.
+ done by using CryptoAPI (unmanaged). From the exceptions
+ thrown Authenticode(tm) support is done via COM.
</ul>
<hr>
*** Namespace: <b>System.Security.Cryptography.Xml</b>
- This namespace implements the XML Digital Signature specification from
- W3C.
+ This namespace implements the <a href="http://www.w3.org/TR/xmldsig-core/">
+ XML Digital Signature</a> specification from
+ <a href="http://www.w3.org/">W3C</a>.
**** Status
<ul>
- * All classes are present but some are only stubbed.
+ * All classes are present but some (Transforms) are only
+ stubbed.
* Most classes have their unit tests.
- * This assembly is present in CVS but isn't (yet) part of the
- build.
+ * This assembly is present in CVS but only available when
+ building using NAnt (i.e. makefile are missing).
</ul>
**** TODO
<ul>
* All the transforms needs to be done. But this requires far
- more XML knowledge than crypto.
+ more XML knowledge than crypto. Note: Most tests runs because
+ the feeded XML is pre-c14n (by hand in the code) before
+ 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.
- * Fix the tests (see notes) then include the assembly into the
- build process.
- </ul>
-
-**** Notes
- <ul>
- * Many current tests fails because the XML generated by Mono
- isn't exactly the same as the one produced by the Microsoft
- implementation (but 100% equivalent). We'll either have to
- change the XML code or the tests.
-
- * Testing is difficult because the classes use CryptoConfig
- to create the required cryptographic objects. When running
- the unit tests the CryptoConfig executing is the one in
- mscorlib (not Mono's one) so it doesn't return the expected
- objects. This results in InvalidCastException.
+ * Makefile for building under non-Windows operating systems.
</ul>
<hr>
** Assembly: Mono.Security.Win32
- This assembly is to provide maximum compatibility with CryptoAPI to
- application running with Mono's runtime on the Windows operating
+ This assembly goal is to provide maximum compatibility with CryptoAPI
+ to application running with Mono's runtime on the Windows operating
system.
<b>This assembly should NEVER be used directly by any application</b>.
<ul>
* A RNGCryptoServiceProvider built on top of CryptoAPI.
- * Not (yet) commited in CVS.
+ * Wrapper classes for unmanaged versions of hash 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
<ul>
- * Unmanaged versions of hash algorithms (SHA1 and MD5).
- * Unmanaged versions of symmetric encryption algorithms
- (like DES, TripleDES, RC2 and others present in CryptoAPI).
- * Unmanaged versions of asymmetric algorithms (like DSA and
- RSA) which persist their keypair into the specified CSP.
+ * 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>
<hr>
certificates.
Note: WSE is distributed as an add-on because the WS-Security
- specification isn't yet completed by OASIS.
+ specification isn't yet completed by
+ <a href="http://www.oasis-open.org/committees/wss/">OASIS</a>.
<b>There are some licensing issues to consider before stating to
implement WS-Security. All contributors must sign an agreement with
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).
**** Status
re-used in source code (C# or VB.NET syntax).
* <code>cert2spc</code> is a tool to transform multiple X.509
- certificates (a chain) into a Software Publisher Certificate
- (SPC) - which is a long name for a simple PKCS#7 file.
+ certificates and CRLs into a Software Publisher Certificate
+ (SPC) file - which is a long name for a simple PKCS#7 file.
</ul>
**** TODO
<ul>
* <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.
+ library) and as such is written in C and won't run without Mono.
- * <code>signcode</code> and <code>chktrust</code> for signing
- and validating Authenticode(tm) signatures on assemblies.
+ * <code>signcode</code> and <code>chktrust</code> (in progress)
+ 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.
Add missing unit tests to classes or methods.
Write some documentation on the cryptographic classes for MonkeyGuide
- (as I'm not a good writer - but you must be a good reader if you got to
- this part).
+ (as I'm not a good writer, at least in English, but you must be a good
+ reader if you got to this part).
Optimization can also be done on algorithms as crypto is never fast
enough. Just be sure to test every optimization (using the unit test)
, <a href="mailto:spouliot@motus.com">work</a>) if you need additional
informations about the status of the cryptographic classes.
+<hr>
+Last reviewed: February 5, 2003 (post mono 0.19)
projects / mono.git / blobdiff