On 21/09/2012 6:00 a.m., Alex Rousskov wrote:
On 09/20/2012 05:32 AM, Amos Jeffries wrote:
On 20/09/2012 10:54 p.m., Tsantilas Christos wrote:
Hi Amos,
I show you had already fix most of my mistakes in wiki page. Thank you.
On 09/20/2012 09:40 AM, Amos Jeffries wrote:
On 20/09/2012 9:40 a.m., [email protected] wrote:
+
+ result::
+ The result code '''OK''' indicates that the certificate validation
is successful. The result code '''ERROR''' indicates that an error
occurred.
"ERR" is the standard result code opposite to "OK" (ie invalid
certificate on succcessful lookup). For helper internal errors please
use "BH" with a message= key-pair.
OK. Just returning "OK" or "BH" for certificate validation is enough,
because helper is just overwritting or rechecking the SSL errors.
This is what we do in the first implementation we have...
I think we should continue doing that: return OK regardless of the
number of certificate problems confirmed or identified by the validator.
Consider what question the helper is trying to answer? "is certificate
valid"
OK/ERR make perfect sense as possible responses when you understand that
both are "success". One meaning valid certificate, one meaning non-valid
certificate.
BH the code for "broken helper" internal errors, independent of the
certificate validity.
But we may want to rerurn "OK" only if the validator found the
certificate good (no errors returned) and "ERR" if exist errors in one
of the certificates.
Opinions?
Yes that is consistent with the other helpers.
I would not return ERR or ERROR when the validation helper is
successfully answering a validation request. Whether the helper found or
confirmed some invalid certificates is irrelevant -- it successfully did
what it was asked to do.
That is not what OK means.
Both OK and ERR mean the helper has successfully done what it was asked
to do. OK being the positive result, ERR the negative result. These
semantics are laid out by the existing authentication and ACL interfaces
which are where OK/ERR come from.
I am pushing for the BH result code from NTLM/Kerberos to be added so we
can distinguish between the three true/false/error states. The use of
letters "ERR" is unfortunate, but what we are stuck with for now at least.
ERR or ERROR makes sense if, for example, the validation request itself
was invalid but the helper is running fine and can accept the next request.
Yes it does make sense. However we should aim for simplicity and
consistency with the existing helper protocols which all use ERR as a
negative success result. The two protocols which differentiate response
results from helper errors use BH code instead of ERR. For now at least
I think it is a good idea to continue with the existing style.
This is similar to a web server returning a page with bad news content
using 200 OK status code.
It is even more smilar to a boolean conditional test responding true
whenever all the arguments exist regardless of their values.
From there server point of view, everything is
OK
... but a certificate is invalid. Not-OK.
-- it is just doing its job and does not care whether it delivers bad
news, good news, or no news at all.
This is not just a helper status field this is a test result AND helper
status field.
Amos
