Hello Steve, Thus wrote Dr. Stephen Henson (st...@openssl.org):
> Sorry for not replying to your private mail. I'd been considering how to do > this and several other things got in the way. No problem. It's good that we get the discussion started now. > I don't think hard coding NIDs into the verify routines is the way to go. The > new EVP_PKEY API in 1.0.0 is intended to remove as much of that stuff as > possible. Ok, understood. > The best approach IMHO is to have a new "pss" public key algorithm to handle > the case of PSS only keys and pass the ASN1 structures down to the specific > method API via the ctrl mechanism. Hm, not sure if I understand this. Do you suggest having a new value for EPV_PKEY's type field to indicate pss? (Can't figure out quickly if type contains a NID_... value) PSS parameters would then be added to rsa_st? A while ago, I tried a new THIS_IS_PSS flag for EVP_PKEY's rsa_st. It worked but I'm not sure if it was a good approach. Probably, the EVP_PKEY_CTX was introduced to store such information... > The existing RSA methods could also then switch to pss if the appropriate > structures are present. > I realise that's a bit vague at present, I'll have a think about it a bit > more. Another thought: Yesterday, I looked at EVP_PKEY_ASN1_METHOD. This has a pub_decode funktion (rsa_pub_decode() for RSA) that prepares an EVP_PKEY from the ASN1 infos about an X.509 public key. The resulting EVP_PKEY is later passed to ASN1_item_verify(). Could we change this to prepare an EVP_PKEY_CTX instead? Best regards, Martin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
