To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=62684
------- Additional comments from [EMAIL PROTECTED] Tue Mar 14 08:42:07 -0800 2006 ------- 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. Another idea would be this: In XMLSec one iterates over certificates and converts the issuer name to a string which is then compared with the issuer string. However, the function to create a string (CertNameToStr on Windows) can be used with several flags which modify the apearance of the string. Because XMLSec does not know in what way the issuer string was created (that was passed to xmlSecDSigCtxSign) it would have to create the string in all possible ways to compare them. Another problem is that in our xmlsecurity the "S" attribute is replaced by "ST" because mozilla cannot handle "S". A simple string comparison is therefore not possible. The best way would be to use OIDs together with raw data (e.g. 1.2.3=#09233249). This would be unambigous. The time and effort would be rather high, because we have to implement some DER encoding and decoding ourselves or find a 3rd party libray which fits our needs. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
