9/21/2003 Aleksey
	Copule issues with certs verification:
	1) Currently the only "trusted" certs are ones loaded to xmlsec directly (for 
	example, using xmlsec command line utility "--trusted" option). This means that
	code does not accept trusted certs in MS Crypto store as such. There are some functions
	that allow to check against trusted certs in MS Crypto store. But MSDN says that
	these functions are not available in Windows 95/98/Me and partially not available 
	in NT 4.0 and Windows 2000. Anyone interested in more details feel free to search
	for "Certificate Chain Verification Functions" article in MSDN. For me, it sounds
	like it would be possible to use these new functions but I think it would be good
	to have a runtime version check:
		- if it's old Windows then use current code;
		- if it's new Windows with new functions then use some new code.
	If you are interested in this functionality, feel free to contribute :)

	2) Curerntly the cert chain construction/verification function is recursive. It's 
	not too difficult to use a loop instead but I don't think this is important too 
	much. If you do then feel free to submit a patch :)
	

9/21/2003
	Issuer/serial of certificates lookup and writing is now
	supported. The conversion from and to xml integer
	representation of the serial number has something odd (I
	think), the MS Cert serial must be word base swapped... Why??? 
	
	Certificate lookup is now extended:
	When the xmlsec application is started, with the config
	parameter the name of the (system) keystore can be given. That
	keystore will be used for certificate (=key) lookup.
	With the keyname now two types of values can be given:
	simple name (called friendly name with MS)
	full subject name (recommended) of the certificate that is
	searched.

9/14/2003
	3 fixes: 
	1) The keyname was not set when a certificate (key) was
	retrieved from MS Certificate store and transferred to the
	(cache) simple keystore (This resulted in errors in key lookup
	procedures).
	2) Symmetric key import failed, when keysize of given key was not
	exact same size as key definition. Now a bigger size then
	needed kan be given to SetKey, following behaviour of rest of
	xmlsec library
	3) RSA keyimport changed, so imported keys are allowed to be used
	for signing *and* encryption, instead of only for signing.


9/11/2003
	Support for DSA has been added: DSA keys (certificates) and
	DSA-SHA1 signatures are now supported. 

	Support for pkcs12 keys is implemented.

	Support for native RSA/DSA public keys is implemented.

	mscrypto/Keysstore has changed a lot: Different approach in
	handling ms keys is now implemented.

	A word about AES. It is supported, but on my machine the AES
	provider is registered with the extra word (optional) in the
	identifier string. This is now also in the code. I hope MS
	will soon fix this and support AES as they have docummented
	it.

	Loads of bugs have been fixed. This results into successfully
	running a lot of tests (use nmake check to run the
	tests). Unfortunately the test suite is not really suited for
	running in a native windows environment: Cygwin is needed to
	run the tests. This gives some problems: 
	1) /tmp folder is in the sh at a different location then in
	the application (xmlsec.exe) (c:\cygwin\tmp versus c:\tmp) on
	my machine. It means you need c:\tmp folder to run the
	tests. 
	2) Since the working directory is xmlsec/win32, instead of
	xmlsec, some files with keys are not found. (Causes raw-cert
	sig test to fail, for example.)
	3) Thirdly the command diff is used, but this may result into
	finding differences in files simply because of the original
	file may have lf and the newly generated files have crlf as
	linebreaks. Use diff --strip-trailing-cr to avoid these
	problems. 
	4) With the diff option files generated by the xmlsec.exe
	command are compared. The files are created in c:\tmp folder,
	but in the shell /tmp is c:\cygwin\tmp (on my machine). Add
	/cygdrive/c before the filename variable.
	5) Since HMAC is not supported at all, the generate keys
	fails. All key generations are done in 1 command.
	6) Apparently the keys from the encryption tests from phaos
	tests are not read/imported correctly, or possibly something
	in the import code is wrong. This results in lots of
	failures. Since plain private key import is not supported,
	decryption without using pkcs 12 keys is not supported.
	7) Most other failures at my site are the results of not
	implemented functionalities.
	Fixing the problems without breaking unix/linux environments
	will take some effort, but should be done at the end. I would
	prefer an environment for windows where cygwin is not needed :)

9/3/2003
	Apparently there is no native support for RSA OAEP in MS
	Crypto API. MS indicates that they will support this in the
	near future.

	Interoperatibility tests are done with success for 3des,
	RSA-PKCS1 keytransport, SHA1, RSA-SHA1 signning and verifying
	against the OpenSSL library.

8/31/2003
	First initiall release for the mscrypto support in xmlsec lib.
	What is in the code so far:

	- SHA1 hashing (tested, and tested against OpenSSL)
	- Symmetric encryption: 3des-cbc (tested), AES128, AES192, AES256
	  (untested).
	- RSA-SHA1 signatures (tested)
	- RSA keys (not direct RSA keys yet, but only through MS
	  Certificatestore) (tested)
	  - x509 certificates (and CRL support), partly, the loading
	    and keyinfo parts are partly done. (partly tested)
	    - x509 certificate verification. Untested, and very
	      limited at this moment.
	- KeyManager implementation. Wrapper for simplekeystore, with
	  backup search facility to the MS Certificate store. Very 
	  limited search capabilities at this time, certificates in
	  MS certificate store can only be found with their 'friendly 
	  name' (which is the CN of the subject dn, as far as I know).
	- RSA-PKCS1 keytransport. Only the creation (encryption) part is
	  tested.

	What will be in the code soon as far as I'm concerned:
	- RSA-OAEP keytransport
	- DSA signatures
	- Better search facilities for finding certificates in the MS
	  certificate store.
	- ???

	What is still missing then:
	- HMAC support
	- AES/3des key transport
	- direct keys (without ms certificate store certificates) support.
	- ???

WHAT VERSION OF WINDOWS?
------------------------

The xmlsec-mscrypto lib is developed on a windows XP machine with
Visual Studio .NET. The MS Crypto API has been evolving a lot with the
new releases of windows and internet explorer. MS CryptoAPI libraries
are distributed with ie and with the windows OS. Full functionality
will only be achieved on windows XP. AES is for example not supported
on pre XP versions of windows (workarounds for this are possible, I
believe). Direct RSA de/encryption, used by xmlsec-mscrypto, is only
possible from Win 2000 (possibly also with a newer version of ie, with
strong encryption patch installed). It's very likely more of these
issues are lying around, and until it is tested on older windows
systems it is uncertain what will work.

KEYS MANAGER with MS Certificate store support. 
-----------------------------------------------

xmlsec-mscrypto keys manager uses a custom keys store. This store is
based upon the simple keys store, found in the xmlsec core library. If
keys are not found in the simple keys store, than MS Certificate store
is used to lookup keys. The certificate store is only used on a
READONLY base, so it is not possible to store keys via the keys store
into the MS certificate store. There are enough other tools that can
do that for you.
