> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Blumenthal, Uri - 0553 - MITLL > Sent: Thursday, March 24, 2016 16:37 > > 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. It can be quite illuminating, if tiresome, to step through the verification of a non-trivial chain in the OpenSSL 1.0.1 code. (I haven't tried it in other versions; maybe it's more readable in 1.1.0, with more-meaningful identifier names and the like, but there's a limit to how much it could be streamlined.) It's been over a year since I last did this, but if memory serves, part of what it does is, as certificates are verified, it adds them to a "now trusted" list. Perhaps calling verify again could produce a false verify-OK because OpenSSL will stop checking when it hits one of those, and not find a verification failure further along the chain. 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. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
