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.
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
