<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Sorry for the top post, I'm wring this on an iPad on a plane.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Mike</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Oct 14, 2015, at 18:35, Langer, Christoph <<a href="mailto:christoph.langer@sap.com">christoph.langer@sap.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Mike,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">thanks for your comments on this.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I’d say this is not quite right,
too. Because, if you have loaded a different provider on top of the providers list, you’ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException – however, it would still
be difficult to find the root cause why a certificate could not be loaded.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">What do you think?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">@all: Are there other opinions?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks and best regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Christoph<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="color:windowtext;mso-fareast-language:DE">From:</span></b><span lang="EN-US" style="color:windowtext;mso-fareast-language:DE"> security-dev [<a href="mailto:security-dev-bounces@openjdk.java.net">mailto:security-dev-bounces@openjdk.java.net</a>]
<b>On Behalf Of </b>Mike StJohns<br>
<b>Sent:</b> Mittwoch, 14. Oktober 2015 02:17<br>
<b>To:</b> <a href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><br>
<b>Subject:</b> Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi - <br>
<br>
I took a look and this probably isn't the correct way to fix this. <br>
<br>
A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach?<br>
<br>
The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;")<br>
<br>
Mike<br>
<br>
<br>
On 10/12/2015 5:04 PM, Langer, Christoph wrote:<span style="font-size:12.0pt;mso-fareast-language:DE"><o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">please review a change proposal regarding an issue in the Microsoft Security API (mscapi).</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8139436">
https://bugs.openjdk.java.net/browse/JDK-8139436</a></span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Webrev: <a href="http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/">
http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/</a></span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now,
such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you’ll get exceptions like:</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at java.security.KeyStore.getCertificate(KeyStore.java:1095)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">At that point it is not obvious what the real root cause for that is.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">With my change, loading of the keystore would already throw like this:</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at java.security.KeyStore.load(KeyStore.java:1459)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> ... 3 more</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER!</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> ... 5 more</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">This is more obvious when it comes to analyzing such an issue.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Also, I added a property “sun.security.mscapi.ignoreFailingCertificates” which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly
interested in a failing certificate.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:
<a href="http://jcewww.iaik.tu-graz.ac.at/sic/Download">http://jcewww.iaik.tu-graz.ac.at/sic/Download</a> (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Would you think this change is reasonable and worthwile?</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Thanks & Best regards</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Christoph</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:DE"><o:p> </o:p></span></p>
</div>
</div></blockquote></body></html>