On 3/25/16, 16:10 , "openssl-users on behalf of Michael Wojcik" <openssl-users-boun...@openssl.org on behalf of michael.woj...@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.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
