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
