Issue 103519 - xmlsecurity: Signature certificate names are trunked if CN contains commas enclosed withing quotes
Summary: xmlsecurity: Signature certificate names are trunked if CN contains commas en...
Alias: None
Product: xml
Classification: Code
Component: code (show other issues)
Version: OOO310m11
Hardware: All All
: P2 Trivial with 4 votes (vote)
Target Milestone: OOo 3.2
Assignee: h.ilter
QA Contact: issues@xml
Depends on:
Reported: 2009-07-13 17:21 UTC by clawgrip
Modified: 2017-05-20 09:30 UTC (History)
2 users (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 clawgrip 2009-07-13 17:21:14 UTC
we're working on a project for promoting the use of the new (smartcard and
certificate based) Spanish National ID Card (called DNIe) on Open Source
environments. The project is promoted by CENATIC, a working group of Spanish
public administration organisms (Spanish Ministry of Industry and some local and
regional governments among others) and some private corporations (Atos Origin
Spain, Sun Microsystems Spain, etc.).

 Within the scope of our project, we've found a few interoperability problems
between the DNIe and (OOo). I'll try to describe the problem and
how we're trying to fix it (you can find our patch at the end of this description):

Problem description:

When parsing RFC 2253 DN's for showing the available certificates for signing
the current document to the user, OOo does the tokenizer directly using the ','
character as separator, but the Spanish National ID Card (smartcard-based) has
certificates with their principals according to the following format:


So, instead of showing the Common Name as:


OOo shows:


Because the ',' between SURNAME1 and SURNAME2 is interpreted as token separator.

The bug is critical, since there are two certificates on the Spanish ID card,
one for digital signature and the other for authentication, with CNs as:


But OOs shows them as:


That is, with the same description for both certificates, which leads users to
confusion, because you cannot identify which certificate is for signing and
which is for authentication.

Our Fix:

Now, ',' characters enclosed between a pair of '"' characters are not
interpreted as token separators.

We've changed only the "String GetContentPart( const String& _rRawString )"
method of the OOO310_m11/xmlsecurity/source/dialogs/resourcemanager.cxx file,
but not the other variants (there's at least another variant that allows to
choose which RDN to retrieve, "String GetContentPart( const String& _rRawString,
const String& _rPartId )"), mainly because only the changed one was used for
showing certificate descriptions (CNs) to the users.

We've contacted Peng Chandler (author of the patched code), and although he
finds the patch right, since he's no longer involved on OOo development he
suggested we should send the patch and bug description to OOo directly.

Please, don't hesitate to ask for any other information or change you need.


--- OOO310_m11/xmlsecurity/source/dialogs/resourcemanager.cxx	2008-04-11
02:14:16.000000000 +0200
+++ OOO310_m11/xmlsecurity/source/dialogs/resourcemanager.cxx	2009-07-07
14:31:10.000000000 +0200
@@ -219,7 +219,25 @@
                 nContStart = nContStart + sPartId.Len();
                 //++nContStart;                   // now it's start of content,
directly after Id // delete By CP
-                xub_StrLen nContEnd = _rRawString.Search( sal_Unicode( ',' ),
nContStart );
+                xub_StrLen nContEnd = STRING_NOTFOUND;
+                xub_StrLen nTempPos = nContStart;
+                do {
+                    xub_StrLen nNextCommaPos = _rRawString.Search( sal_Unicode(
',' ), nTempPos );
+                    xub_StrLen nInvComBegin = _rRawString.Search( sal_Unicode(
'"' ), nTempPos );
+                    if(nInvComBegin == STRING_NOTFOUND || nInvComBegin >=
+                        nContEnd = nNextCommaPos;
+                    else
+                    {
+                        xub_StrLen nInvComEnd = _rRawString.Search(
sal_Unicode( '"' ), nInvComBegin+1 );
+                        if(nInvComEnd == STRING_NOTFOUND)
+                            nContEnd = nNextCommaPos;
+                        else
+                            nTempPos = nInvComEnd+1;
+                    }
+                } while (nContEnd == STRING_NOTFOUND);
                 sPart = String( _rRawString, nContStart, nContEnd - nContStart );
Comment 1 joachim.lingner 2009-07-14 15:32:10 UTC
May I ask if you have already submitted  a Sun Microsystems Inc. Contributor
Agreement (SCA) (look here:
Only then can I use the patch as provided.
Comment 2 clawgrip 2009-07-16 13:16:15 UTC
Although I've developed the patch, it belongs to CENATIC (, 
so, a CENATIC representaive will send the contributing form ASAP.
Comment 3 joachim.lingner 2009-08-27 13:00:52 UTC
Comment 4 joachim.lingner 2009-08-27 13:04:34 UTC
Actually there was a bit more involved in fixing this. The original function did
not take into account that the value string is enclosed if it contains special
characters and that quotes, which belong to the value, are escaped by another quote.
Comment 5 joachim.lingner 2009-08-27 13:06:18 UTC
@hi: I can provide a test document if you  need one.
Comment 6 joachim.lingner 2009-08-27 13:07:28 UTC
Comment 7 h.ilter 2009-09-10 10:31:39 UTC
Verified with cws encsig09 = ok