OpenSSL supports RSA-OAEP and RSA-PSS. See the latest documentation for the 'cms' command for details. At present, PSS-only and OAEP-only keys in certificates are not supported.
Russ On 11/20/2013 05:18 PM, Richard Barnes wrote: > That makes sense. Would you say the same in the signature domain, i.e., > PKCS#1 v1.5 -> PSS? > > > On Wed, Nov 20, 2013 at 12:07 PM, Russ Housley <[email protected]> wrote: > >> I do not know of any place where RSA-OAEP has been called out as the >> mandatory to implement algorithm, but there are many places where PKCS#1 >> v1.5 still enjoys this status. I suggest we make RSA-OAEP the mandatory to >> implement algorithm in our specifications. >> >> Russ >> >> >> On Nov 20, 2013, at 11:09 AM, Richard Barnes wrote: >> >> What are you proposing be done, besides supporting OAEP in new specs or >> back-porting it to old ones? In order to make people use OAEP, we would >> need to call in the protocol police. >> >> >> On Wed, Nov 20, 2013 at 10:49 AM, Russ Housley <[email protected]>wrote: >> >>> We have known for a ver long time that PKCS #1 Version 1.5 (see RFC 2313) >>> is vulnerable to adaptive chosen ciphertext attacks when applied for >>> encryption purposes. Exploitation reveals the result of a particular RSA >>> decryption, requires access to an oracle which will respond to a hundreds >>> of thousands of ciphertexts), which are constructed adaptively in response >>> to previously-received replies providing information on the successes or >>> failures of attempted decryption operations. As a result, the attack >>> appears significantly less feasible to perpetrate in store-and-forward >>> environments than for interactive ones. >>> >>> PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to >>> address this situation, but we have seen very little movement toward >>> RSA-OAEP. While we are reviewing algorithm choices in light of the >>> pervasive surveillance situation, I think we should take the time to >>> address known vulnerabilities like this one. If we don't, then we are >>> leaving an partially open door for a well funded attacker. >>> >>> Russ >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >>> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
