PKIXRevocationChecker and ocsp stapling

[Sean Mullan]

On 6/3/19 1:16 PM, Michał Zegan wrote:
>> It says in PKIXParameters.setRevocationEnabled [1]:
>>
>> "Sophisticated applications should set this flag to false when it is not
>> practical to use a PKIX service provider's default revocation checking
>> mechanism or when an alternative revocation checking mechanism is to be
>> substituted (by also calling the addCertPathChecker or
>> setCertPathCheckers methods)."
> It is unclear if adding my own instance of PKIXRevocationChecker (even
> if it's the provider's implementation) is considered replacing a default
> mechanism or not, so it is at least unclear.
>> and in the PKIXRevocationChecker API [2]:
>>
>> "When supplying a revocation checker in this manner, it will be used to
>> check revocation irrespective of the setting of the RevocationEnabled
>> flag."
> Yes. However here I would always think if it means that the checker
> would be called twice or recognized. Note that if you supply a
> revocation checker in*this*  manner, it is normal that it will be used
> because it is in a list of checkers, so the question is more like if the
> default instance of revocation checker will be used if another one is
> passed and setRevocationChecking(true) is set... and this is not really
> clear from the documentation. That is my line of thinking when I read it
> and this is the reason why I looked at the code.

I agree, it can be confusing. Suggested rewording:

"When supplying a revocation checker in this manner, it will be used to
check revocation irrespective of the setting of the RevocationEnabled
flag, and if the RevocationEnabled flag is true, the default revocation 
checker of the PKIX service provider will not be used."

--Sean