Hi Tomas, thanks for this - IIRC I already saw similar effects with other ID cards.
May I ask you to file an issues for this, and attach the patch (which was cut off by the mailing list anyway)? The owner would be "jl". Thanks and best regards, Malte. PS: You might want to look at our new security project security.openoffice.org, and subscribe to the corresponding mailing list [email protected] Tomas GARCIA-MERAS CAPOTE wrote, On 07/12/09 23:12: > Hello, > 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 OpenOffice.org (OOo). I'll try to describe the problem > and how we're trying to fix it (you can find our patch attached): > > 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: > > CN="NAME SURNAME1, SURNAME2 > (CERTUSE)",givenNAME=NAME,SN=SURNAME,serialNumber=... > > So, instead of showing the Common Name as: > > "NAME SURNAME1, SURNAME2 (CERTUSE)" > > OOo shows: > > "NAME SURNAME1 > > 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: > > "NAME SURNAME1, SURNAME2 (SIGNATURE)" > "NAME SURNAME1, SURNAME2 (AUTHENTICATION)" > > But OOs shows them as: > > "NAME SURNAME1 > "NAME SURNAME1 > > 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. > Also, it would be nice to know if the bug and patch are being accepted or not > ¿Can you please keep us updated? > > TIA. Best regards: Tomás > > ------------------------------------------------------------------ > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos Origin > group liability cannot be triggered for the message content. Although > the sender endeavours to maintain a computer virus-free network, > the sender does not warrant that this transmission is virus-free and > will not be liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener informacion confidencial > destinada solamente a la(s) persona(s) mencionadas anteriormente > pueden estar protegidos por secreto profesional. > Si usted recibe este correo electronico por error, gracias por informar > inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin > no se hace responsable por su contenido. Su contenido no constituye ningun > compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas > partes. > Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor > no puede garantizar nada al respecto y no sera responsable de cualesquiera > danos que puedan resultar de una transmision de virus. > ------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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]
