Re: sun.security.provider.certpath.DistributionPointFetcher
Can you provide the code to reproduce the exception? Or is it possible attach
the CertPath building debugger log?
Xuelei
On Jun 28, 2011, at 11:59 AM, David Pomeroy wrote:
> Hello All,
>
> I am trying to get a servlet to download and check a CRL. The CRLDP is in
> the client's certificate and the CRL is marked "indirect CRL" so that it can
> be signed by a different key than the client cert issuer. The following
> block of code is invoked but the DistributionPointFetcher can't seem to build
> a valid path and a CRLException is thrown. My assumption was this would work
> if I included the CRL signing certificate in my truststore. What I find odd
> while stepping through this in a debugger is that the "certStores" object
> contains only the client certificate which is to be validated, so it makes
> sense that X509CertSelector doesn't find the right cert in there.
>
> Has anyone got indirect CRLs validated before? I'd be interested in the
> details of a test setup that works. I can provide more details of my test
> setup if necessary.
>
> Thanks, David
>
>
> // Obtain and validate the certification path for the complete
> // CRL issuer (if indirect CRL). If a key usage extension is present
> // in the CRL issuer's certificate, verify that the cRLSign bit is
> set.
> if (indirectCRL) {
> X509CertSelector certSel = new X509CertSelector();
> certSel.setSubject(crlIssuer.asX500Principal());
> boolean[] crlSign = {false,false,false,false,false,false,true};
> certSel.setKeyUsage(crlSign);
> PKIXBuilderParameters params = null;
> try {
> params = new PKIXBuilderParameters
> (Collections.singleton(anchor), certSel);
> } catch (InvalidAlgorithmParameterException iape) {
> throw new CRLException(iape);
> }
> params.setCertStores(certStores);
> params.setSigProvider(provider);
> try {
> CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
> PKIXCertPathBuilderResult result =
> (PKIXCertPathBuilderResult) builder.build(params);
> prevKey = result.getPublicKey();
> } catch (Exception e) {
> throw new CRLException(e);
> }
> }
Re: sun.security.provider.certpath.DistributionPointFetcher
On Jun 29, 2011, at 4:51 AM, David Pomeroy wrote: > Hi Sean, > > openjdk7 complained that my Crl Server certificate did not contain a Subject > Key Identifier. It's a must-to-have field to comply with RFC 5280. > Once I added this, validating the indirect CRL issuer worked as expected. > Glad to know it works in JDK 7. > When I switched back to openjdk6, the CRL validation still fails. I have > attached the certpath debug from each jvm. If you look at the line > "certpath: SunCertPathBuilder.engineBuild([", jdk6 only adds my Sub CA > certificate as a trusted source, where jdk7 adds all 3 certs from the > truststore, including the Crl Issuer's certificate. Perhaps jdk6 is looking > for specific criteria in the trusted certificates for use in validating the > CRL? > > When I switched back to sun jdk 6, I got a different error. It's as if it is > not even trying to build a verification path at all. I attached that debug > as well. > > Thanks for jdk7 suggestion, I definitely learned something. However, I'd > really like to get this working on a version 6 jvm. Any workaround > suggestions from you or the group would be greatly appreciated. No known workaround. You may be able to disable certificate status checking in the default provider, and check the certificate status by a customized PKIXCertPathChecker. Xuelei > > Thanks, Dave > > > On Tue, Jun 28, 2011 at 11:14 AM, Sean Mullan wrote: > On 6/28/11 1:01 PM, David Pomeroy wrote: > Hi Sean, > > I am using Open JDK 6. Are the indirect CRL bugs in JDK 6 documented > anywhere? > Are there any workarounds? > > See: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6509162 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6542169 > > No known workarounds. It would help if you tested with JDK 7 [1] so we could > verify if the problem has fixed. > > If it still fails with JDK 7, please file a bug (and attach a test program) > at http://bugs.sun.com > > Thanks, > Sean > > [1] http://jdk7.java.net/download.html > > > I am setting enableCRLDP. > > Thanks, Dave > > On Tue, Jun 28, 2011 at 5:46 AM, Sean Mullan <mailto:[email protected]>> wrote: > >Are you using JDK 7? There were some bugs fixed with indirect CRLs in JDK > 7. > > Also, make sure you set the system property com.sun.security.enableCRLDP > to the >value true when running, ex: java -Dcom.sun.security.__enableCRLDP=true ... > >--Sean > > >On 6/28/11 1:05 AM, [email protected] wrote: > >Can you provide the code to reproduce the exception? Or is it possible >attach >the CertPath building debugger log? > >Xuelei > >On Jun 28, 2011, at 11:59 AM, David Pomeroy<mailto:[email protected]>> wrote: > > >Hello All, > >I am trying to get a servlet to download and check a CRL. The > CRLDP >is in >the client's certificate and the CRL is marked "indirect CRL" so > that it >can be signed by a different key than the client cert issuer. The >following block of code is invoked but the DistributionPointFetcher >can't >seem to build a valid path and a CRLException is thrown. My >assumption was >this would work if I included the CRL signing certificate in my >truststore. >What I find odd while stepping through this in a debugger is that > the >"certStores" object contains only the client certificate which is > to be >validated, so it makes sense that X509CertSelector doesn't find the >right >cert in there. > >Has anyone got indirect CRLs validated before? I'd be interested > in the >details of a test setup that works. I can provide more details of >my test >setup if necessary. > >Thanks, David > > >// Obtain and validate the certification path for the complete // > CRL >issuer (if indirect CRL). If a key usage extension is present // in >the CRL >issuer's certificate, verify that the cRLSign bit is set. if >(indirectCRL) >{ X509CertSelector certSel = new X509CertSelector(); >certSel.setSubject(crlIssuer.__asX500Principal()); boolean[] > crlSign = >{false,false,false,false,__false,false,true}; >certSel.setKeyUsage(crlSign); >
Re: Code review request: 7059709, java/jsse, close the IO in a final block
I found the bug when I was learning the t-w-r feature. But just as Stuart
thoroughly analysis, I failed to find a easy way to use t-w-r for these two
updates.
Thanks for all of the feedback.
Xuelei
On Jun 29, 2011, at 6:44 AM, Brad Wetmore wrote:
> While I was thinking the same thing as Sean/Stuart, it's not clear how much
> risk you would be refactoring a lot of code just to use this language feature.
>
> It's pretty clear (to me anyway) what you were intending here.
>
> Brad
>
>
>
>
> On 6/28/2011 1:31 PM, Stuart Marks wrote:
>> On 6/28/11 11:46 AM, Sean Mullan wrote:
>>> On 6/27/11 9:29 PM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7059709/webrev.00/
>>>
>>> It seems you could restructure this code by moving the instantiation
>>> of the
>>> FileInputStream down just before the KeyStore.load and use a
>>> try-with-resources
>>> block instead.
>>
>> I had thought of this too but using try-with-resources for either of
>> these cases isn't obvious.
>>
>> One difficulty is that the FileInputStreams are only initialized if some
>> condition is true, otherwise they're left null. That is, simplified,
>>
>> FileInputStream fis = null;
>> if (...condition...) {
>> fis = ...initialization...
>> }
>> // process fis if non-null
>>
>> To use try-with-resources, you'd have to do something like put the
>> conditional within the initialization expression. The only way to do
>> this in-line in Java is to use the ternary (?:) operator, like so:
>>
>> try (FileInputStream fis = ...condition... ? ...initialization... : null) {
>> // process fis if non-null
>> }
>>
>> or the conditional could be evaluated prior to the try, with the
>> resource variable being an alias:
>>
>> FileInputStream fis = null;
>> if (...condition...) {
>> fis = ...initialization...
>> }
>> try (FileInputStream fis2 = fis) {
>> // process fis2 if non-null
>> }
>>
>> or even by refactoring the conditional initialization into a separate
>> method:
>>
>> try (FileInputStream fis = openFileOrReturnNull(...)) {
>> // process fis if non-null
>> }
>>
>> Another approach would be to call KeyStore.load() from the different
>> condition arms, instead of conditionally initializing a variable:
>>
>> if (...condition...) {
>> try (FileInputStream fis = ...initialization...) {
>> ks.load(fis, passwd);
>> }
>> } else {
>> ks.load(null, passwd);
>> }
>>
>> This initializes the input streams closer to where they're used, but
>> this might change the behavior if an error occurs while opening the
>> stream; additional initializations or even side effects might occur
>> before the error is reached. I haven't inspected the code thoroughly to
>> determine whether this is the case. It also puts big initialization
>> expression into the t-w-r, which might be ugly.
>>
>> Now, as you might know, I'm a big fan of try-with-resources, but using
>> it here brings in a potentially large restructuring. This might or might
>> not be warranted for this particular change; I don't know the tradeoffs
>> involved in this code.
>>
>> s'marks
Re: On 7063702: To interprete case-insensitive string locale independently
I did not check all directories. I think we may need to evaluate them in the same CR or according to modules. Andrew On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: > Hi Xuelei > > There are some other places using equalsIgnoreCase(). Is this method safe for > all locales? > > Thanks > Max
Re: On 7063702: To interprete case-insensitive string locale independently
On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: > Hi Xuelei > > There are some other places using equalsIgnoreCase(). Is this method safe for > all locales? > equalsIgnoreCase() is safe. Looking into the code of this method, you will find that the implementation is a little different from just converting to lower case or upper case. Andrew > Thanks > Max
Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror
On Jul 21, 2011, at 1:25 AM, Alexandre Boulgakov
wrote:
> This is a Netbeans warning, not generated by the compiler. The reason is that
> List.isEmpty() can be more efficient for some implementations.
> ArrayList.size() == 0 and ArrayList.isEmpty() should take the same time, so
> it doesn't matter for allResults, but keyTypeList is a List argument, so any
> implementation could be passed in. List.isEmpty() should never be slower than
> List.size() == 0 because AbstractCollection defines isEmpty() as size() == 0.
>
> Even if we don't get a performance improvement, it still improves readability.
>
Sounds reasonable.
Thanks,
Xuelei
> -Sasha
>
> On 7/19/2011 7:32 PM, Xuelei Fan wrote:
>> I was looking at the updates in sun/security/ssl. Looks fine to me.
>>
>> It's fine, but I just wonder why List.isEmpty() is preferred to
>> (List.size() == 0). What's the compiler warning for (List.size() == 0)?
>>
>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
>> -if (keyTypeList == null || keyTypeList.size() == 0) {
>> +if (keyTypeList == null || keyTypeList.isEmpty()) {
>>
>> -if (allResults == null || allResults.size() == 0) {
>> +if (allResults == null || allResults.isEmpty()) {
>>
>> Thanks for the cleanup.
>>
>> Thanks,
>> Xuelei (Andrew) Fan
>>
>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote:
>>> Hello Sean,
>>>
>>> Have you had a chance to look at this webrev?
>>>
>>> Thanks,
>>> Sasha
>>>
>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote:
Hello,
Here's an updated webrev:
http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/
I've reexamined the @SuppressWarnings("unchecked") annotations, and
added comments to all of the ones I've added. I was was also able to
remove several of them by using covariant return types on
sun.security.x509.*Extension.get(String) inherited from Object
CertAttrSet.get(String). I've also updated the consumers of
sun.security.x509.*Extension.get(String) to use the more specific
return type, removing several casts and @SuppressWarnings("unchecked")
annotations.
Also, please take a closer look at my changes to
com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry,
final CodeSource) in
src/share/classes/com/sun/security/auth/PolicyFile.java lines
1088-1094. The preceding comment and the behavior of
Subject.getPrincipals(Class) seem to be more consistent with the
updated version, but I wanted to make sure.
The classes where I added serialVersionUID's are either new or have
the same serialVersionUID as the original implementation.
Thanks,
Sasha
On 7/18/2011 5:33 PM, Brad Wetmore wrote:
> (Apologies to folks without access to the older sources.)
>
>
> On 07/18/11 15:00, Sean Mullan wrote:
>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
>>> Is there an easy way to see when a class was added to the JDK?
>> For standard API classes, you can use the @since javadoc tag which
>> will indicate
>> the release it was first introduced in.
> Standard, exported API classes. Some of the underlying support
> classes for API packages like java.*.* weren't always @since'd properly.
>
>> For internal classes, there is no easy way, since most don't have an
>> @since tag.
>> I would probably write a script that checks the rt.jar of each of
>> the JREs that
>> are archived at /java/re/jdk. The pathnames should be fairly
>> consistent, just
>> the version number is different.
> Don't know which classes you're talking about here, but some classes
> started out in other jar files and eventually wound up in rt.jar.
> Also, some files live in files other than rt.jar. I usually go to
> the source when looking for something. If it's originally from
> JSSE/JGSS/JCE, you'll need to look on our restricted access machine.
>
> When I'm looking for something that is in the jdk/j2se workspaces, I
> go right to the old Codemgr data, specifically the nametable file,
> because many times the files you want may be in a src//classes
> instead of src/share/classes.
>
> % grep -i SunMSCAPI.java
> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable
>
> % grep -i SunMSCAPI.java
> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable
> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4
> a217f6b0 6c833bd3 d4ef32be
>
> That will usually give you a good starting point.
>
> Brad
>
>
>
>
> Depending on rt.jar or not.
>
>> Chris, do you have any other ideas?
>>
>> --Sean
