PKIXRevocationChecker and ocsp stapling

[Michał Zegan]

W dniu 03.06.2019 o 18:58, Jamil Nimeh pisze:
> Hi Sean and Michal, one comment in-line below:
> 
> On 6/3/2019 7:45 AM, Sean Mullan wrote:
>> Hi,
>>
>> On 6/1/19 8:29 AM, Michał Zegan wrote:
>>> Hello,
>>> I believe I have found a bug but not quite sure if it is in
>>> documentation or jdk impl itself. I currently have no code example, but
>>> I looked into the jdk code itself.
>>> This
>>> https://docs.oracle.com/en/java/javase/11/security/java-pki-programmers-guide.html#GUID-43A3A247-E165-408C-AD74-88A75BFB4750
>>>
>>> actually suggests that when using the own instance of
>>> PKIXRevocationChecker, you should disable default revocation by
>>> PKIXParameters.setRevocationEnabled(false)
>>
>> Not completely true. You should disable revocation checking if you are
>> passing in an subclass of PKIXCertPathChecker (and not
>> PKIXRevocationChecker) because the JDK implementation doesn't know if
>> it is a revocation checker or not. But if you pass in a
>> PKIXRevocationChecker (this API was added later in JDK 1.8) it doesn't
>> matter if the revocation flag is enabled or not, it will be recognized
>> and get used instead of the default one.
>>
>>> and it actually seems to be
>>> suggested by api docs too even though it is not stated there directly.
>>
>> 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)."
>>
>> 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."
>>
>> (Although we should probably add a similar statement to the
>> setRevocationChecker API so it is more clear).
>>
>>> However:
>>> - first, from what I know, if revocation is enabled by
>>> setRevocationEnabled and a custom PKIXRevocationChecker is added, then
>>> this fact is respected correctly by the validator implementation, it can
>>> be seen in the code.
>>
>> Right.
>>
>>> - on the other hand, if it is disabled, then you can still add the
>>> checker, but for example ocsp stapling in jsse probably will stop
>>> working.
>>> It is because sun.security.validator.PKIXValidator's addResponses method
>>> works only if revocationEnabled is true.
>>
>> Good catch - that looks like a bug.
> Not so sure about that.  OCSP stapling doesn't function independently of
> PKIXValidator.  It uses it and all its settings. As far as JSSE is
> concerned, OCSP stapling is a means of delivery for the responses, just
> as client-driven OCSP can be a means of delivery.  If revocation
> checking is disabled, no matter what PKIXRevocationChecker is in
> existence, if any, those in-band responses won't be part of the decision
> to proceed with the handshake or not.
Well actually shouldn't you decide on using ocsp stapling based on added
revocation checkers? Unless you specifically want it to function even in
case of custom rev checker, but this custom rev checker can extend
PKIXRevocationChecker... well not sure.
Or you could check for the flag and checker, and presence of one or both
triggers it (like the default checker is not added before you call the
validator). Or it would need improvements to documentation.
> 
> That means that you can end up with a case where rev checking is turned
> off and OCSP stapling still happens as part of the handshake, which is
> admittedly oddball.  There's a bug already filed to make it so the
> client never asserts status_request[_v2] when revocation checking is
> turned off (JDK-8181505).  But it's not as easy to fix as it sounds
> because we lose visibility into the PKIXRevocationChecker's revocation
> settings well before the evaluation to enable or disable the TLS
> extension.  But that's my problem to figure out.  :)
>>
>>> What is even more weird, the method seems to honour the fact that user
>>> could add his own PKIXRevocationChecker, but for it to work it has to be
>>> done *and* revocationEnabled needs to be true.
>>
>> Yes, that should not be required.
>>
>>> Seems like a confusion/inconsistency. Not quite sure if this is a bug in
>>> the code, or more in the documentation, and what is the correct
>>> approach.
>>> Note I didn't actually test this (I don't have any ocsp whatever). It is
>>> just what I read when looking at jdk code, so my findings could be
>>> wrong.
>>
>> Thanks for spotting this. I will file a bug on your behalf.
>>
>> --Sean
>>
>> [1]
>> https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/security/cert/PKIXParameters.html#setRevocationEnabled(boolean)
>>
>> [2]
>> https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/security/cert/PKIXRevocationChecker.html
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190603/eb265b43/signature.asc>