It leaves the specifier of the parameters free to pick ones subject to arbitrary non-disclosed criteria, subject to the limitation that criteria happen frequent

It leaves the specifier of the parameters free to pick ones subject to arbitrary non-disclosed criteria, subject to the limitation that criteria happen frequently enough relative to how many times he can afford to run SHA1. E.g. If he can afford to run SHA1 2^32 times as part of preparing a curve, he can pick curves that have non-disclosed strengthening or weakening factors which tend to be found at random 1:2^32 times or more often. Basically it shows that the parameters are random subject to a computationally bounded attacker. But the bound is unrealistic: They're only random if the attacker tries only once. As the attacker tries multiple times, he gains selection over the parameters proportional to his effort. E.g. he could pick curves that have twists with particular structure, or which are have pairings to extension fields which he could solve the discrete log problem in. (This is only mostly speculative: Certainly there are weak curves which occur with this frequency, the procedure itself directly excludes one type: supersingular curves. If we didn't know that the DLP problem was trivial over super-singular curves then this exact procedure could have selected for them or excluded them without revealing that the selecting party was doing anything non-public.) This wouldn't be alarming to me except for how trivial it would be to provide a higher level of assurance in exactly the same framework: Start with an initial sleeve provably specified after the framework with no control over it, and increment it one at a time and take the first set of parameters that pass. Failing that, a very low entropy set of parameters (like starting at zero and incrementing) would produce good evidence that the parameter selecting party wasn't selecting based on hidden characteristics. I note that the brainpool curves (http://tools.ietf.org/html/rfc5639 http://tools.ietf.org/html/rfc5639) come much closer what I'd expected had been done here.