Issue 62684 - xmlsecurity: Investigate why certificate from isis-mtt does not work
Summary: xmlsecurity: Investigate why certificate from isis-mtt does not work
Alias: None
Product: xml
Classification: Code
Component: code (show other issues)
Version: 680m156
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0.3
Assignee: frank
QA Contact: issues@xml
Keywords: security
: 60142 63058 (view as issue list)
Depends on:
Reported: 2006-03-01 14:49 UTC by joachim.lingner
Modified: 2008-01-11 14:08 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description joachim.lingner 2006-03-01 14:49:01 UTC
Comment 1 joachim.lingner 2006-03-01 14:49:51 UTC
Comment 2 joachim.lingner 2006-03-01 14:57:01 UTC
This affects the L1User1 certificate from the isis-mtt testbed.
Comment 3 joachim.lingner 2006-03-14 16:42:07 UTC
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
<>) 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"
( 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:
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.
Comment 4 joachim.lingner 2006-03-14 16:44:06 UTC
If we implemented the use of raw data ( etc.) then we loose
backward compatibility. The signature of a document will not be recognized with
an older version of OOo.
Comment 5 joachim.lingner 2006-03-15 11:08:36 UTC
Comment 6 joachim.lingner 2006-03-20 11:19:33 UTC
*** Issue 60142 has been marked as a duplicate of this issue. ***
Comment 7 joachim.lingner 2006-03-20 11:22:48 UTC
Instead of relying that the external XML Sec library finds a certificate by
issuer name we now provide the whole certificate during the signing operation.
Comment 8 joachim.lingner 2006-03-30 10:09:03 UTC
jl->fst: Please verify. I will provide the necessary certificates and keys.

re-open issue and reassign to
Comment 9 joachim.lingner 2006-03-30 10:09:06 UTC
reassign to
Comment 10 joachim.lingner 2006-03-30 10:09:09 UTC
reset resolution to FIXED
Comment 11 frank 2006-04-06 14:24:41 UTC
found fixed on cws jl32. Checked on Solaris, Linux and Windows
Comment 12 frank 2006-05-09 11:58:15 UTC
found integrated on master m167 using Linux, Solaris and Windows build
Comment 13 joachim.lingner 2006-05-22 09:33:17 UTC
*** Issue 63058 has been marked as a duplicate of this issue. ***
Comment 14 joachim.lingner 2008-01-11 14:08:50 UTC
added security keyword