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>
