W dniu 03.06.2019 o 22:34, Sean Mullan pisze: > 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." Hmm, not quite sure about wording, but would definitely be more clear. Thanks. > > --Sean
signature.asc
Description: OpenPGP digital signature
