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

List:       bouncycastle-crypto-dev
Subject:    RE: [dev-crypto] PKIXCertPathBuilderSpi queries all CertStores
From:       <Clement_Pellerin () ibi ! com>
Date:       2007-05-17 16:54:04
Message-ID: 8EC4F0A8AC7A6D40BF9C55E32249A916017416AD () IBIUSMBSA ! ibi ! com
[Download RAW message or body]


I personally believe that if the certificate returned is not valid,
then all other remaining CertStores will return the same invalid
certificate under my assumption. This falls under user preference.

Maybe we could change setAdditionalLocationsEnabled() to an enumerated
attribute UseAdditionalLocations with 3 values:
no, stop on first match, all

As long as your added RFC 3280 functionality does not break our
RFC2587 CertStore, this would be OK.


-----Original Message-----
From: Karsten Ohme [mailto:widerstand@t-online.de] 
Sent: Thursday, May 17, 2007 12:32 PM
To: Pellerin, Clement
Cc: dev-crypto@bouncycastle.org
Subject: Re: [dev-crypto] PKIXCertPathBuilderSpi queries all CertStores

Clement_Pellerin@ibi.com schrieb:
> I'm interested to see how we can take advantage of your RFC 3280
> functionaliy.
> 
> On the other hand, I don't understand what you mean by first run.
> Are you proposing I call the CertPathBuilder twice, once with a
limited
> set
> of CertStores, and if that fails, then call it again with the
additional
> LDAP CertStore?
> We can do that today with the current PKIXCertPathBuilder.

OK, fine.

> 
> The CMS container can contain all/some/no certificates in the signer
> certificate path.
> Since we know the CMS SignerIdentifier will select the signer
> certificate uniquely,
> we can do better and stop the loop in
> PKIXCertPathBuilderSpi.findCertificates()
> as soon as one CertStore returns a non-empty result. This handles all
> cases
> in just one run.

It could be the case that the returned certificate is not valid. This
can only be determined during validation phase not the building phase.
So this would not be generally correct. But the above solution works, so
in some weeks this will work.

> 
> 
> -----Original Message-----
> From: Karsten Ohme [mailto:widerstand@t-online.de] 
> Sent: Thursday, May 17, 2007 11:02 AM
> To: Pellerin, Clement
> Cc: dev-crypto@bouncycastle.org
> Subject: Re: [dev-crypto] PKIXCertPathBuilderSpi queries all
CertStores
> 
> Clement_Pellerin@ibi.com schrieb:
>> We use PKIXCertPathBuilder to verify the signature of S/MIME
messages.
>> The certificates in the S/MIME message is the first CertStore.
>> CMS allows the sender to omit the signer certificate path to shrink
>> down the message size. To complete the certificate path, we use an
>> additional LDAP CertStore. The second CertStore is orders of
magnitude
>> more costly to query than the first. If we found the certificate in
>> the CMS message, there is no point in wasting resources to query
>> LDAP to retrieve the exact same information.
> 
> I have implemented some new concept and required changes to make BC
> PKITS (RFC 3280) compliant. Look at the class
> org/bouncycastle/x509/ExtendedPKIXParameters.java. There is a mathod
> setAdditionalLocationsEnabled() and a method addAddionalStore(). An
> additional store is e.g. an LDAP store. If you disable to look in
> additional stores in the first run, you can speed up to validation. It
> will last some time until this changes are included. Until now you can
> use only the CertStore created from the certificates in the CMS
> container.
> 
> Regards, Karsten
> 
>> -----Original Message-----
>> From: Karsten Ohme [mailto:widerstand@t-online.de] 
>> Sent: Wednesday, May 16, 2007 8:42 PM
>> To: Pellerin, Clement
>> Cc: dev-crypto@bouncycastle.org
>> Subject: Re: [dev-crypto] PKIXCertPathBuilderSpi queries all
> CertStores
>> Clement_Pellerin@ibi.com schrieb:
>>> I looked at the source code of BC 1.35  The implementation of the
>>> PKIXCertPathBuilder in BC queries all CertStores to collect all
> target
>>> certificates. The Sun implementation in JDK 1.6 stops with the first
>>> CertStore that returns something (when building the path in the
>> forward
>>> direction). How could we achieve the same thing in BC? We do not
want
>> to
>>> distribute a patch on top of BC. We would prefer a solution to be
> part
>>> of a standard BC distribution.
>>>  
>> What's wrong with this? Why is it bad to use all CertStores and test
> all
>> certificates until a valid certification path is found?
>>
>> Regards,
>> Karsten
>>
> 



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