[xmlsec] Finding certificates with subject name and serial number

[Joachim Lingner]

Hi all,

When using X.509 certificates and their respective private keys for 
signing a document then the template passed to xmlSecDSigCtxSign 
contains the subject name and the serial number. This information is 
used by XMLSec to find the certificate and key in the certificate store. 
This may often fail because of the way the  certificate is  searched 
for. The nss or windows api provide functions which search for a 
certificate based on a DER encoded subject name. They only yield the 
certificate if the passed in name matches bit by bit the subject name of 
the certificate. To use these functions one has to create the DER 
encoded name first based on the subject name contained in the template. 
The subject name is a Distinguished Name and each attribute value can 
have a different string type, for example PrintableString, Utf8String, 
UniversalString. The  information about what attribute value is encoded 
using which type is usually not contained in the subject name. Therefore 
it is not possible to make an unambiguous conversion into the DER 
encoded format. Because the string types are part of the encoded name, a 
false type makes the name different to the name of the certificate. 
Hence the certificate cannot be found.

There is also a bug in bugzilla (118631 
<http://bugzilla.gnome.org/show_bug.cgi?id=118631>) which deals with 
this problem.

The Windows API (CertStrToName, CryptEncodeObject)  does not allow to 
specify the types of the attribute values when encoding the string. They 
use build-in rules to determine the type. CertStrToName uses mostly 
Printable String or T61 String. If a certificate uses other string 
types, then they cannot be found using the currently employed algorithm 
in XMLSec. For example, RFC 3280 states that all certificates created 
since 2004 should use UTF8. Those certificates cannot be used currently, 
because they cannot be found.

The W3C recommendation "XML-Signature Syntax and Processing" 
(http://www.w3.org/TR/xmldsig-core/#sec-X509Data) states that the 
subject name should adhere to RFC2253. This would allow to form a 
distinguished name where each attribute value remains encoded, for example:

1.3.6.1.4.1.1466.0=#04024869
Here the first byte of the value ('04') represents the type.


The Windows function CertStrToName understands this syntax only partly. 
It gives the value always the type Octet String, which makes it unsuable 
in this case. In order to use this kind of representation for subject 
names, XMLSec would have to do some DER encoding on its own.


How do you see this problem? Is there any work-around known?

Best regards
Joachim Lingner