Jump to navigation

Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.
Otherwise you may find some unperfect stuff here...

Weblog

Extensions Hunt 2005

There is a lot of new stuff related to X.509 certificates in the next version of the .NET framework. Some hunters may have noticed the support for X.509 certificate extensions. However the number of supported extensions is rather small compared to Mono.Security.dll - itself small against the extensions defined by X.509 and PKIX. A quick hunt would show...

  • X509BasicConstraintsExtension;
  • X509EnhancedKeyUsageExtension;
  • X509KeyUsageExtension; and
  • X509SubjectKeyIdentifierExtension

in the System.Security.Cryptography.X509Certificates namespace of the System.Security.dll (which makes a very long FQN).

Actually the most useful extensions, at least from an TLS/SSL point of view, are presents. Only lacking, wrt the existing SSL implementation of Mono.Security.dll, is the older "Netscape Cert Type" extension. This isn't a big deal since the class hierarchy make it easy to add new, problem-specific, extensions.

Previous versions, like the 1.2 preview of PDC 2003, showed that the classes had some strange behaviors. They seemed a lot knowledgeable, deep down to System.Security.Cryptography.AsnEncodedData, but were very buggy to convert (and still are). I opened quite a few bugs on MSDN Product Feedback on them and (mostly) forgot them until now.

Now to help Carlos on the new (2.0) SslStream class I decided to fully implement the X509Extension derived classes, then proceed to create an internal class for the NetscapeCertType extension. I quickly found out that I couldn't, cleanly, get the same results as the original without overriding some methods (yes I could and I did but it's not as clean as I wanted).

It didn't make much sense for Microsoft to design the classes in that way - unless... this OO design was hiding something else. From there it was easy to see what was going under the hood - as similar design decisions can be seen in other cryptography classes inside corlib.

The AsnEncodedData knows "everything" (well maybe not where Jackson's wallet is at the moment but everything more ASN related). You can easily see this by creating an instance with some ASN.1 then call Format(false) - it knows a lot!

So all the other classes are the pretty OO around this centralized knowledge. Why ? Well I guess for the same reasons as the crypto stuff, i.e. CryptoAPI.

A good test to be sure is to try an extension unknown to the framework like... the Netscape Cert Type extension.

AsnEncodedData nct = new AsnEncodedData (new byte[] { 0x03, 0x02, 0x01, 0x06} ); Console.WriteLine (nct.ToString (false));
SSL CA, SMIME CA (06)

Et voila!

Now the hunt is open as I don't have any clue how many extensions (and other stuff like PKCS #9 attributes) are inside CryptoAPI. IIRC this is extensible by adding new DLL in Windows but I don't recall seeing a "complete" list of the built-in extensions/attributes anywhere. Anyone seen it ? If not then I guess it's time to exercise our hunting skills ;-)


1/17/2005 15:39:16 | Comments

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.