PKIXRevocationChecker and ocsp stapling

[Sean Mullan]

On 6/3/19 5:40 PM, Michał Zegan wrote:
> 
> 
> 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.

I filed a couple of issues on this, one for improving the specification, 
and another for the bug in OCSP stapling. (They could be fixed together, 
but I kept them separate since depending on which phase we are in, it 
may not be possible to fix RFEs):

https://bugs.openjdk.java.net/browse/JDK-8225433
https://bugs.openjdk.java.net/browse/JDK-8225436

--Sean