[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    [security-dev 01748]: 6522064: Keystore aliases from MS CryptoAPI have bad encoding
From:       boris.dusek () gmail ! com (=?UTF-8?B?Qm9yaXMgRHXFoWVr?=)
Date:       2010-03-30 11:55:07
Message-ID: b2c603da1003300455x5fa09ab9n77dc15cde4de395c () mail ! gmail ! com
[Download RAW message or body]

Hello,

this is my first time contributing to Java or Sun (Oracle), so please
forgive me if I am doing something wrong.

I am writing because I met an issue with JSignPdf app and my testing
certificates, which contain non-ASCII characters in my name (and so in CN
field) [1]. So I found it's bug 6522064, and after a bit of hesitation, I
downloaded the OpenJDK bundle for the first time and pin-pointed the issue
down to src/windows/native/sun/security/mscapi/security.cpp, line 389, where
CertGetNameString gets called in the "ANSI" version instead of Unicode
version (bug 1), and what is more, converted into java String with
NewStringUTF (bug 2).

A quick test I then made was to make the call specifically reference the
Unicode version (CertGetNameStringW) along with needed changes for this. The
result was that the issue was fixed [2]. I am sending the patch in
attachment to give you an idea of the problem and as a "proof of concept",
but know that there are still questions to be answered to determine maybe
more correct and systematic ways to fix/code this:

1. Is there a reason the security.cpp file (or even the entire JDK) is not
built with UNICODE macro defined, so that functions like CertGetNameString
automatically expand to their Unicode variants (CertGetNameStringW) and so
that as a result Unicode is used throughout the place? Would it be a big
deal to turn UNICODE on for the file (provided I fix the calls to Unicode)?

2. Do you think it's OK to convert all calls in security.cpp to Unicode
(either explicitely with the "W" suffix to function name, or by defining
UNICODE macro), or should only enough to fix the bug be converted (i.e. as
in the patch)? Or more generally, what is the smallest unit of code that has
to be converted (just the function, the whole security.cpp file, or the
whole "security" directory?

3. What about unit tests for this issue? Do you think it's possible (or
desirable) to write a unit test for this? If (according to point 2.) whole
file gets fixed, then I think creating a certificate in Java with non-ASCII
characters in CN and then storing and getting such certificate from Windows
Certificate Store fails because no cert with that alias is found, that could
be a test, but are such changes (adding certificate) to testing system OK
for unit tests?

4. For testing, I am building the sunmscapi.dll just from the security.cpp
file (to avoid building the whole JDK6 - I am using latest "user" JRE 6 from
java.com), and statically link the C++ runtime from VC9 (to avoid using VC
2003, which I don't have). Should I still build the whole JDK (I have only
VC2008 Express)? If yes, should I build and test jdk6, or jdk7 (security.cpp
is unchanged between jdk6 and jdk7).

5. If I do work on this, is there any special location I should send the SCA
to? The "deadline" for SCA is before someone commits the change, or am I
late by not having it sent before sending this email?

Please let me know your comments and suggestions.

Thanks,
Boris Du?ek

[1]: http://www.flickr.com/photos/48318243 at N04/4476189180/
[2]: http://www.flickr.com/photos/48318243 at N04/4476189652/  - for fun, the
names are, in order, Shimon Peres, Yellow Horse in Czech, Gandhi, Mohammed
bin Rashid Al Maktoum, Mao Zedong, and Sergei Rachmaninoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100330/87829ea3/attachment.html \
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mscapi_unicode_alias.diff
Type: application/octet-stream
Size: 2505 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100330/87829ea3/mscapi_unicode_alias.diff \



[prev in list] [next in list] [prev in thread] [next in thread]