[openssl-users] X509_verify_cert cannot be called twice

[Blumenthal, Uri - 0553 - MITLL]

On 3/25/16, 16:10 , "openssl-users on behalf of Michael Wojcik"
<openssl-users-bounces at openssl.org on behalf of
Michael.Wojcik at microfocus.com> wrote:


>>I'm sure I'm missing something obvious, but why isn't the operation
>> XXX_verify_xxx() idempotent? It seems very weird that two subsequent
>> calls to verify() wouldn't return exactly the same thing.
>
>Viktor already alluded to why it's not idempotent, and if you look
>through the relevant code for a bit I think you can see why. The short
>answer is that it uses the (verification) context to keep a lot of state.
>When it finishes, the context is no longer in a state that's suitable for
>restarting the verification process, as currently implemented.

I think the keywords here are “as currently implemented”. I have no
problem accepting Viktor’s and your answers why *the current
implementation* behaves the way it does. But why is it not re-implemented
in a friendlier way?

>...
>So while it might seem like verify *ought to* be idempotent, in fact it
>represents a substantial transformation on the context which the existing
>code cannot reverse. That doesn't actually strike me as all that strange,
>to be honest. The OpenSSL API in effect boils down to: prepare for
>verification, perform verification, clean up verification. I don't see
>anything that implies the middle step wouldn't irreversibly change state.

Perhaps these three stages could/should be wrapped into a single API that
*internally* does these three steps? Especially since it does not look
like any of those steps can be re-used on its own?

As for “nothing implies..." - usually people assume that operations like
“read”, “verify” (unlike “write”, “set”), do not change the state of the
object involved. 

If I ask “if your passport valid”, I expect to be able to repeat this
question and (as long as this all is within a reasonably short time) get
exactly the same answer.

Although once the current state of the API is explained, I’m happy enough
to just use all the three steps if/when cert verification is needed.
Documentation seems reasonably clear:

The negative return value from X509_verify_cert() can only occur if no
certificate is set in ctx (due to a programming error); if
X509_verify_cert() twice without reinitialising ctx in between; or if a
retry operation is requested during internal lookups (which never happens
with standard lookup methods). It is however recommended that application
check for <= 0 return value on error.


But reference (URL) to “verify” page
(https://www.openssl.org/docs/manmaster/crypto/verify.html) is broken:

The requested URL /docs/manmaster/crypto/verify.html was not found on this
server.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160325/86cd660e/attachment-0001.bin>