Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-11 Thread Erwann ABALEA 
Hodie VII Id. Mar. MMX, Dr. Stephen Henson scripsit:
 On Tue, Mar 09, 2010, Erwann ABALEA wrote:
 
  I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
  few days ago (German passports), with the same error
  (d2i_ECPKParameters function).
  
  The verification of the root against itself is OK, though.

 Well that doesn't check the signature any more unless you include 
 -check_ss_sig

Hmmm... Thanks, this option doesn't appear in the help text.

  Of course, the verification of a subordinate certificate against the
  root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.
 
 That's odd they both verify fine here.
 
 Do you have any of the old patch code in place? I ended up using a completely
 different technique in HEAD.

You were right, I certainly still had some of the old patch. With a
new version freshly exported and compiled, everything's fine, both
RSASSA-PSS and ecdsa-with-SHA256. Thanks.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
When uncertain, or in doubt, run in circles and scream.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Erwann ABALEA 
Hodie post. Non. Mar. MMX, Stephen Henson via RT scripsit:
 I've now committed code to the development branch which includes PSS
 signature verification support. I'll look into PSS signing at some point
 too.
 
 Let me know of any problems.

I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
few days ago (German passports), with the same error
(d2i_ECPKParameters function).

The verification of the root against itself is OK, though.

Of course, the verification of a subordinate certificate against the
root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Dr. Stephen Henson 
On Tue, Mar 09, 2010, Erwann ABALEA wrote:

 Hodie post. Non. Mar. MMX, Stephen Henson via RT scripsit:
  I've now committed code to the development branch which includes PSS
  signature verification support. I'll look into PSS signing at some point
  too.
  
  Let me know of any problems.
 
 I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
 few days ago (German passports), with the same error
 (d2i_ECPKParameters function).
 
 The verification of the root against itself is OK, though.
 

Well that doesn't check the signature any more unless you include -check_ss_sig

 Of course, the verification of a subordinate certificate against the
 root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.
 

That's odd they both verify fine here.

Do you have any of the old patch code in place? I ended up using a completely
different technique in HEAD.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Martin Kaiser via RT 
Hello Steve,

Thus wrote Stephen Henson via RT (r...@openssl.org):

 I've now committed code to the development branch which includes PSS
 signature verification support.

thanks for committing this, it looks like a clean and generic approach. 

(of course, it's a pity that most of my code didn't make it into the
final version but that's life...)

 I'll look into PSS signing at some point too.

Any chance I can contribute to this, based on your approach for
verification?

A while ago, I extended my patch to support basic PSS signing. For this,
I added a -pss command line parameter to x509 which uses the default PSS
parameters and does not explicitly encode them. Instead, an empty
sequence is used to indicate default parameters.

 Let me know of any problems.

It runs ok against the sample certificates that I have here.

Do you think it makes sense to check the trailerField in
rsa_item_verify() to make sure that it is the default value?

Index: crypto/rsa/rsa_ameth.c
===
RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_ameth.c,v
retrieving revision 1.24
diff -u -r1.24 rsa_ameth.c
--- crypto/rsa/rsa_ameth.c  8 Mar 2010 18:10:35 -   1.24
+++ crypto/rsa/rsa_ameth.c  9 Mar 2010 21:55:22 -
@@ -530,6 +530,13 @@
else
saltlen = 20;
 
+   /* low-level routines support only trailer field 0xbc (value 1) */
+   if (pss-trailerField  ASN1_INTEGER_get(pss-trailerField) != 1)
+   {
+   RSAerr(RSA_F_RSA_ITEM_VERIFY, RSA_R_INVALID_TRAILER);
+   goto err;
+   }
+
/* We have all parameters now set up context */
 
if (!EVP_DigestVerifyInit(ctx, pkctx, md, NULL, pkey))


BTW, ticket #2131 is now obsolete ;-)

Best regards,

   Martin


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Dr. Stephen Henson 
On Tue, Mar 09, 2010, Martin Kaiser via RT wrote:

 Hello Steve,
 
 Thus wrote Stephen Henson via RT (r...@openssl.org):
 
  I'll look into PSS signing at some point too.
 
 Any chance I can contribute to this, based on your approach for
 verification?
 
 A while ago, I extended my patch to support basic PSS signing. For this,
 I added a -pss command line parameter to x509 which uses the default PSS
 parameters and does not explicitly encode them. Instead, an empty
 sequence is used to indicate default parameters.
 

I'll have to think about that a bit more. I really want a general solution
where you can use all sorts of different algorithm types and parameters, both
at an application level and on the command line. There isn't currently an
actual framework to do that and some new APIs will be needed.

I'm divided between something which uses ASN1 pre-setup to obtain the
parameters (which measn you need a generalised API to setup the ASN1 in the
first place) or something which takes an EVP_PKEY_CTX and uses that to setup
the ASN1. The latter is cleaner and already has application and command line
APIs but needs some way to transparently extract the data from an
EVP_PKEY_CTX: which is opaque at an application level. Some ctrls to get md's,
padding modes, salt lengths etc would work.

  Let me know of any problems.
 
 It runs ok against the sample certificates that I have here.
 
 Do you think it makes sense to check the trailerField in
 rsa_item_verify() to make sure that it is the default value?
 
 Index: crypto/rsa/rsa_ameth.c
 ===
 RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_ameth.c,v
 retrieving revision 1.24
 diff -u -r1.24 rsa_ameth.c
 --- crypto/rsa/rsa_ameth.c  8 Mar 2010 18:10:35 -   1.24
 +++ crypto/rsa/rsa_ameth.c  9 Mar 2010 21:55:22 -
 @@ -530,6 +530,13 @@
 else
 saltlen = 20;
  
 +   /* low-level routines support only trailer field 0xbc (value 1) */
 +   if (pss-trailerField  ASN1_INTEGER_get(pss-trailerField) != 1)
 +   {
 +   RSAerr(RSA_F_RSA_ITEM_VERIFY, RSA_R_INVALID_TRAILER);
 +   goto err;
 +   }
 +
 /* We have all parameters now set up context */
  
 if (!EVP_DigestVerifyInit(ctx, pkctx, md, NULL, pkey))
 
 

Yes thanks, I'll add that.

BTW is anyone has or knows of any samples of CMS messages signed with PSS let
me know. Also anyone with samples using PSS only keys: those definitely wont
work at present.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Martin Kaiser 
Hi Erwann,

Thus wrote Erwann ABALEA (erwann.aba...@keynectis.com):

 I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
 few days ago (German passports), with the same error
 (d2i_ECPKParameters function).

this is strange. I've also tested Steven's version against your ecdsa
certificates and things worked ok for me.

 Of course, the verification of a subordinate certificate against the
 root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.

After you reported the problem with my patch, I made an update (which I
couldn't post while the servers were down). I know it's obsolete by now
but I'll attach it anyway. Your ecdsa examples verify ok with this patch.
Maybe this helps to track down your problem.

Best regards,

   Martin
diff --git a/crypto/asn1/a_verify.c b/crypto/asn1/a_verify.c
index d9332ee..cd9f082 100644
--- a/crypto/asn1/a_verify.c
+++ b/crypto/asn1/a_verify.c
@@ -134,14 +134,15 @@ err:
 int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signature,
 	 void *asn, EVP_PKEY *pkey)
 	{
-	EVP_MD_CTX ctx;
-	const EVP_MD *type = NULL;
+	EVP_MD_CTX mctx;
+	const EVP_MD *md = NULL;
+
 	unsigned char *buf_in=NULL;
 	int ret= -1,inl;
 
 	int mdnid, pknid;
 
-	EVP_MD_CTX_init(ctx);
+	EVP_MD_CTX_init(mctx);
 
 	/* Convert signature OID into digest and public key OIDs */
 	if (!OBJ_find_sigid_algs(OBJ_obj2nid(a-algorithm), mdnid, pknid))
@@ -149,12 +150,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM);
 		goto err;
 		}
-	type=EVP_get_digestbynid(mdnid);
-	if (type == NULL)
-		{
-		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_MESSAGE_DIGEST_ALGORITHM);
-		goto err;
-		}
+	md=EVP_get_digestbynid(mdnid); /* md == NULL is no longer an error */
 
 	/* Check public key OID matches public key type */
 	if (EVP_PKEY_type(pknid) != pkey-ameth-pkey_id)
@@ -162,8 +158,42 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_WRONG_PUBLIC_KEY_TYPE);
 		goto err;
 		}
-
-	if (!EVP_VerifyInit_ex(ctx,type, NULL))
+   /* if digest is still unknown, try to check the algorithm parameters */
+   if (!md  pkey-ameth-param_decode  a)
+  {
+  int plen;
+
+  /* this is ok for a-parameter==NULL, result is plen=0 */
+  plen = i2d_ASN1_TYPE(a-parameter, NULL);
+  if (plen  0)
+ {
+ const unsigned char *cp;
+ unsigned char *p;
+ unsigned char *pder=NULL;
+ int ok;
+
+ pder = (unsigned char *)OPENSSL_malloc(plen);
+ if (pder == NULL)
+{
+		  ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_MALLOC_FAILURE);
+		  goto err;
+}
+
+ /* call i2d_...() routines like in pem_pkey.c */
+ p = pder; 
+ plen = i2d_ASN1_TYPE(a-parameter, p);
+ cp = pder;
+
+ ok = pkey-ameth-param_decode(pkey, cp, plen);
+ OPENSSL_free(pder);
+ if (!ok)
+goto err;
+ }
+  }
+
+   EVP_MD_CTX_set_padmode_from_nid(mctx, OBJ_obj2nid(a-algorithm));
+
+	if (!EVP_DigestVerifyInit(mctx, NULL,md, NULL, pkey))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -178,7 +208,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		goto err;
 		}
 
-	if (!EVP_VerifyUpdate(ctx,(unsigned char *)buf_in,inl))
+	if (!EVP_DigestVerifyUpdate(mctx,(unsigned char *)buf_in,inl))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -188,19 +218,19 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 	OPENSSL_cleanse(buf_in,(unsigned int)inl);
 	OPENSSL_free(buf_in);
 
-	if (EVP_VerifyFinal(ctx,(unsigned char *)signature-data,
-			(unsigned int)signature-length,pkey) = 0)
+	if (EVP_DigestVerifyFinal(mctx,(unsigned char *)signature-data,
+			(unsigned int)signature-length) = 0)
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
 		goto err;
 		}
-	/* we don't need to zero the 'ctx' because we just checked
+	/* we don't need to zero the 'mctx' because we just checked
 	 * public information */
-	/* memset(ctx,0,sizeof(ctx)); */
+	/* memset(mctx,0,sizeof(ctx)); */
 	ret=1;
 err:
-	EVP_MD_CTX_cleanup(ctx);
+	EVP_MD_CTX_cleanup(mctx);
 	return(ret);
 	}
 
diff --git a/crypto/evp/evp.h b/crypto/evp/evp.h
index 9064164..fafcc47 100644
--- a/crypto/evp/evp.h
+++ b/crypto/evp/evp.h
@@ -502,6 +502,7 @@ __owur int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in);
 void	EVP_MD_CTX_set_flags(EVP_MD_CTX *ctx, int flags);
 void	EVP_MD_CTX_clear_flags(EVP_MD_CTX *ctx, int flags);
 int 	EVP_MD_CTX_test_flags(const EVP_MD_CTX *ctx,int flags);
+void EVP_MD_CTX_set_padmode_from_nid(EVP_MD_CTX *ctx, int nid);
 __owur int	EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
 __owur int	EVP_DigestUpdate(EVP_MD_CTX *ctx,const void *d,
 			 size_t cnt);
@@ -1038,6

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Dr. Stephen Henson 
On Tue, Mar 09, 2010, Dr. Stephen Henson wrote:

 On Tue, Mar 09, 2010, Martin Kaiser via RT wrote:
 
  Hello Steve,
  
  Thus wrote Stephen Henson via RT (r...@openssl.org):
  
   I'll look into PSS signing at some point too.
  
  Any chance I can contribute to this, based on your approach for
  verification?
  
  A while ago, I extended my patch to support basic PSS signing. For this,
  I added a -pss command line parameter to x509 which uses the default PSS
  parameters and does not explicitly encode them. Instead, an empty
  sequence is used to indicate default parameters.
  
 
 I'll have to think about that a bit more. I really want a general solution
 where you can use all sorts of different algorithm types and parameters, both
 at an application level and on the command line. There isn't currently an
 actual framework to do that and some new APIs will be needed.
 
 I'm divided between something which uses ASN1 pre-setup to obtain the
 parameters (which measn you need a generalised API to setup the ASN1 in the
 first place) or something which takes an EVP_PKEY_CTX and uses that to setup
 the ASN1. The latter is cleaner and already has application and command line
 APIs but needs some way to transparently extract the data from an
 EVP_PKEY_CTX: which is opaque at an application level. Some ctrls to get md's,
 padding modes, salt lengths etc would work.
 

There was something which felt wrong about that idea I couldn't pin down
until I wrote it. I've realised what it is now... we should have a companion
item_sign() function in the EVP_PKEY_ASN1_METHOD and that can get the digest
directly and private key from EVP_MD_CTX. 

Then ASN1_item_sign() becomes ASN1_item_sign_ctx() and ASN1_item_sign()
becomes a special case. I'll consider it a bit more but I think that could
work and as a bonus would tidy up some code that's already there.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-08 Thread Stephen Henson via RT 
I've now committed code to the development branch which includes PSS
signature verification support. I'll look into PSS signing at some point
too.

Let me know of any problems.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-07 Thread Stephen Henson via RT 
I wouldn't advise spending any more time on this. I've been looking into
it more and it the most natural soltuion is an extension to the
EVP_PKEY_ASN1_METHOD structure which I'm currently working on (that
should support some other features too).

Unless I get some major distractions I should be able to get PSS verify
functionality in place sometime this week.

I also want to add PSS signature generation functionality but that will
take a bit longer.

CMS support for PSS would be nice too but I don't have any examples of
PSS signed messages.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-15 Thread Martin Kaiser via RT 
Hello Steve,

thanks for your feedback.

Thus wrote Stephen Henson via RT (r...@openssl.org):

 As has been indicated the PSS ASN1 module is incorrect. Does that
 actually verify PSS signatures correctly with non-default algorithms?
 I'd expect ASN1 parsing errors.

I got Francesco's point and corrected this. The certificates I used for
testing either had the parameters omitted or were generated by myself
using the same wrong definition, that's why I didn't spot the problem.

I'll update the sample certificates on my website shortly
(http://www.kaiser.cx/x509Pss.html)

 A quick look through (I'm not short of things to do at the moment
 alas...) suggests ctrl return codes aren't checked properly in a number
 of places.

Are you refering to this?

   if (type == NULL) 
  {
  if (EVP_PKEY_CTX_ctrl(ctx-pctx, -1, ctx-pctx-operation,
EVP_PKEY_CTRL_PARAM_SET_FROM_PKEY, 0, pkey)) 
 { 
 EVP_PKEY_CTX_ctrl(ctx-pctx, -1, ctx-pctx-operation, 
   EVP_PKEY_CTRL_GET_DIGEST, 0, type);
 }
  

I'll add a clean error checking.

 I also find the lack of any use of the PSS OID as rather strange. The
 specifications I've seen should require it is at least checked.

I've added a function
void EVP_MD_CTX_set_padmode_from_nid(EVP_MD_CTX *ctx, int nid)
that sets EVP_MD_CTX_FLAG_PAD_PSS when it sees the PSS nid. This ctx is
then passed into EVP_DigestVerifyInit.

pkey_rsa_verifyctx_init() converts the flag into RSA_PKEY_CTX' pad_mode
parameter. The pad_mode is checked when the ctrls set the pss
parameters.

Please see the attached patch (against 2010-02-07 snapshot) for a first
concept. Does this make sense to you or does it contradict your intended
use of the (yet unused) EVP_MD_CTX_FLAG_PAD_... flags?

Best regards,

   Martin

diff --git a/crypto/asn1/a_verify.c b/crypto/asn1/a_verify.c
index d9332ee..c5531de 100644
--- a/crypto/asn1/a_verify.c
+++ b/crypto/asn1/a_verify.c
@@ -134,14 +134,15 @@ err:
 int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signature,
 	 void *asn, EVP_PKEY *pkey)
 	{
-	EVP_MD_CTX ctx;
-	const EVP_MD *type = NULL;
+	EVP_MD_CTX mctx;
+	const EVP_MD *md = NULL;
+
 	unsigned char *buf_in=NULL;
 	int ret= -1,inl;
 
 	int mdnid, pknid;
 
-	EVP_MD_CTX_init(ctx);
+	EVP_MD_CTX_init(mctx);
 
 	/* Convert signature OID into digest and public key OIDs */
 	if (!OBJ_find_sigid_algs(OBJ_obj2nid(a-algorithm), mdnid, pknid))
@@ -149,12 +150,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM);
 		goto err;
 		}
-	type=EVP_get_digestbynid(mdnid);
-	if (type == NULL)
-		{
-		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_MESSAGE_DIGEST_ALGORITHM);
-		goto err;
-		}
+	md=EVP_get_digestbynid(mdnid); /* md == NULL is no longer an error */
 
 	/* Check public key OID matches public key type */
 	if (EVP_PKEY_type(pknid) != pkey-ameth-pkey_id)
@@ -162,8 +158,41 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_WRONG_PUBLIC_KEY_TYPE);
 		goto err;
 		}
-
-	if (!EVP_VerifyInit_ex(ctx,type, NULL))
+   if (pkey-ameth-param_decode  a)
+  {
+  int plen;
+
+  /* this is ok for a-parameter==NULL, result is plen=0 */
+  plen = i2d_ASN1_TYPE(a-parameter, NULL);
+  if (plen  0)
+ {
+ const unsigned char *cp;
+ unsigned char *p;
+ unsigned char *pder=NULL;
+ int ok;
+
+ pder = (unsigned char *)OPENSSL_malloc(plen);
+ if (pder == NULL)
+{
+		  ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_MALLOC_FAILURE);
+		  goto err;
+}
+
+ /* call i2d_...() routines like in pem_pkey.c */
+ p = pder; 
+ plen = i2d_ASN1_TYPE(a-parameter, p);
+ cp = pder;
+
+ ok = pkey-ameth-param_decode(pkey, cp, plen);
+ OPENSSL_free(pder);
+ if (!ok)
+goto err;
+ }
+  }
+
+   EVP_MD_CTX_set_padmode_from_nid(mctx, OBJ_obj2nid(a-algorithm));
+
+	if (!EVP_DigestVerifyInit(mctx, NULL,md, NULL, pkey))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -178,7 +207,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		goto err;
 		}
 
-	if (!EVP_VerifyUpdate(ctx,(unsigned char *)buf_in,inl))
+	if (!EVP_DigestVerifyUpdate(mctx,(unsigned char *)buf_in,inl))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -188,19 +217,19 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 	OPENSSL_cleanse(buf_in,(unsigned int)inl);
 	OPENSSL_free(buf_in);
 
-	if (EVP_VerifyFinal(ctx,(unsigned char *)signature-data,
-			(unsigned int)signature-length,pkey) = 0)
+	if (EVP_DigestVerifyFinal(mctx,(unsigned char *)signature-data,
+			(unsigned int)signature-length) = 0)
 		{

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-15 Thread Stephen Henson via RT 
 [li...@kaiser.cx - Mon Feb 15 23:16:48 2010]:
 
 Please see the attached patch (against 2010-02-07 snapshot) for a first
 concept. Does this make sense to you or does it contradict your intended
 use of the (yet unused) EVP_MD_CTX_FLAG_PAD_... flags?
 

Actually that flag isn't unused. It is present in OpenSSL 0.9.8 as a
hack to allow the use of different padding modes using EVP. That was
added for the FIPS 140-2 1.2 module validation. Major infrastructural
changes weren't possible under the constraints of the validation (had to
be binary compatible with 0.9.8) so the smallest compatible change was done.

I wouldn't want to do things that way for 1.0.0 and later because it
isn't flexible enough: it squeezes parameters into one flag. I'll review
your code when I have time. I'd probably go for something similar to the
way the CMS/PKCS7 code works which is to use ctrls inside the
EVP_PKEY_METHOD API..

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: R: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-14 Thread Martin Kaiser 
Hi Francesco and all,

Thus wrote francesco.petru...@innovery.it (francesco.petru...@innovery.it):

 I have a doubt.
 Reading rfc 3447 I see this definition

 RSASSA-PSS-params ::= SEQUENCE {
   hashAlgorithm  [0] HashAlgorithmDEFAULT sha1,
   maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
   saltLength [2] INTEGER  DEFAULT 20,
   trailerField   [3] TrailerField DEFAULT trailerFieldBC
   }

 And I think the params definition in the patch must be changed in

 ASN1_SEQUENCE(RSASSA_PSS_PARAMS) = {
ASN1_EXP_OPT(RSASSA_PSS_PARAMS, hashAlgorithm, X509_ALGOR,0),
ASN1_EXP_OPT(RSASSA_PSS_PARAMS, maskGenAlgorithm, X509_ALGOR,1),
ASN1_EXP_OPT(RSASSA_PSS_PARAMS, saltLength, ASN1_INTEGER,2),
ASN1_EXP_OPT(RSASSA_PSS_PARAMS, trailerField, ASN1_INTEGER,3)
 } ASN1_SEQUENCE_END(RSASSA_PSS_PARAMS)

 ASN1_EXP_OPT for ASN1_OPT

thanks for the correction. RFC3447 clearly says that the tags
are explicit. I'll update the patch accordingly.

Best regards,

   Martin
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

R: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-10 Thread francesco.petruzzi 


I have a doubt.
Reading rfc 3447 I see this definition

RSASSA-PSS-params ::= SEQUENCE {
  hashAlgorithm  [0] HashAlgorithmDEFAULT sha1,
  maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
  saltLength [2] INTEGER  DEFAULT 20,
  trailerField   [3] TrailerField DEFAULT trailerFieldBC
  }

And I think the params definition in the patch must be changed in

ASN1_SEQUENCE(RSASSA_PSS_PARAMS) = {
 ASN1_EXP_OPT(RSASSA_PSS_PARAMS, hashAlgorithm, X509_ALGOR,0),
 ASN1_EXP_OPT(RSASSA_PSS_PARAMS, maskGenAlgorithm, X509_ALGOR,1),
 ASN1_EXP_OPT(RSASSA_PSS_PARAMS, saltLength, ASN1_INTEGER,2),
 ASN1_EXP_OPT(RSASSA_PSS_PARAMS, trailerField, ASN1_INTEGER,3)
} ASN1_SEQUENCE_END(RSASSA_PSS_PARAMS)

ASN1_EXP_OPT for ASN1_OPT



Francesco Petruzzi francesco.petru...@innovery.it 

-Messaggio originale-
Da: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] Per
conto di Martin Kaiser via RT
Inviato: domenica 7 febbraio 2010 20.31
Cc: openssl-dev@openssl.org
Oggetto: Re: [openssl.org #1951] [patch] verification of X.509 certificates
that contain an RSASSA-PSS signature


Dear OpenSSL team and all,

finally, here's my patch (against today's 1.1 snapshot) for verification
of X.509 certificates using an RSASSA-PSS signature. I believe it is
fairly complete in terms of checking parameters.

The patch follows the idea that I outlined in previous posts

- two new ASN.1 objects for pss, mgf1
- in obj_xref.txt, pss uses digest undef
- verify routine has to determine the digest by itself
- ASN1_item_verify() uses EVP_DigestVerify... API
- rsa_st gets two new elements
- param_decode method for rsa parses rsa key's parameters in the
  certificate
- at verification time, pss parameters are copied into EVP_PKEY_CTX

This time, I really do hope to get some feedback. Reviewing this won't
be wasted time, I'm happy to improve the code until it is ready for
merging.

As such pss certificates are now being deployed by the millions for
digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
support them.

Best regards,

   Martin


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-10 Thread Stephen Henson via RT 
 [li...@kaiser.cx - Sun Feb 07 20:31:00 2010]:
 
 
 Dear OpenSSL team and all,
 
 finally, here's my patch (against today's 1.1 snapshot) for verification
 of X.509 certificates using an RSASSA-PSS signature. I believe it is
 fairly complete in terms of checking parameters.
 
 The patch follows the idea that I outlined in previous posts
 
 - two new ASN.1 objects for pss, mgf1
 - in obj_xref.txt, pss uses digest undef
 - verify routine has to determine the digest by itself
 - ASN1_item_verify() uses EVP_DigestVerify... API
 - rsa_st gets two new elements
 - param_decode method for rsa parses rsa key's parameters in the
   certificate
 - at verification time, pss parameters are copied into EVP_PKEY_CTX
 
 This time, I really do hope to get some feedback. Reviewing this won't
 be wasted time, I'm happy to improve the code until it is ready for
 merging.
 
 As such pss certificates are now being deployed by the millions for
 digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
 support them.
 

As has been indicated the PSS ASN1 module is incorrect. Does that
actually verify PSS signatures correctly with non-default algorithms?
I'd expect ASN1 parsing errors.

A quick look through (I'm not short of things to do at the moment
alas...) suggests ctrl return codes aren't checked properly in a number
of places.

I also find the lack of any use of the PSS OID as rather strange. The
specifications I've seen should require it is at least checked.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

R: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-10 Thread francesco.petruzzi 
I have modified the asn1 module of the patch and tested it with other
implementation (iaik).
I successful verify using iaik a timestamp signed by openssl using sha256
RSASSA-PSS, saltlen=64 ,default trailer. Mechanism is ok for me.

Francesco Petruzzi francesco.petru...@innovery.it 
 The information contained in this electronic message and any
attachments (the Message) is intended for one or more specific individuals
or entities,
and may be confidential, proprietary, privileged or otherwise protected by
law. If you are not the intended recipient, please notify the sender
immediately,
delete this Message and do not disclose, distribute, or copy it to any third
party or otherwise use this Message.
Electronic messages are not secure or error free and can contain viruses or
may be delayed, and the sender is not liable for any of these occurrences.
The sender reserves the right to monitor, record and retain electronic
messages.
 Le informazioni contenute in questo messaggio e gli eventuali
allegati (il Messaggio) si intendono inviate a uno o piú specifici
destinatari.
Il contenuto del Messaggio puó essere confidenziale, riservato e comunque
protetto dalla legge applicabile. Se non siete i destinatari del Messaggio,
siete pregati di informare immediatamente il mittente, cancellare questo
Messaggio, non rivelarlo, non distribuirlo ne' inoltrarlo a terzi, non
copiarlo né farne alcun uso.
I messaggi di posta elettronica non sono sicuri e sono soggetti ad
alterazioni, possono essere trasmettitori di Virus informatici o soggetti a
ritardi nella distribuzione.
Il mittente del Messaggio non puó essere in alcun modo considerato
responsabile per queste evenienze.
Il mittente si riserva il diritto di archiviare, ritenere e controllare i
messaggi di posta elettronica. 

-Messaggio originale-
Da: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] Per
conto di Stephen Henson via RT
Inviato: mercoledì 10 febbraio 2010 14.33
A: li...@kaiser.cx
Cc: openssl-dev@openssl.org
Oggetto: [openssl.org #1951] [patch] verification of X.509 certificates that
contain an RSASSA-PSS signature 

 [li...@kaiser.cx - Sun Feb 07 20:31:00 2010]:
 
 
 Dear OpenSSL team and all,
 
 finally, here's my patch (against today's 1.1 snapshot) for verification
 of X.509 certificates using an RSASSA-PSS signature. I believe it is
 fairly complete in terms of checking parameters.
 
 The patch follows the idea that I outlined in previous posts
 
 - two new ASN.1 objects for pss, mgf1
 - in obj_xref.txt, pss uses digest undef
 - verify routine has to determine the digest by itself
 - ASN1_item_verify() uses EVP_DigestVerify... API
 - rsa_st gets two new elements
 - param_decode method for rsa parses rsa key's parameters in the
   certificate
 - at verification time, pss parameters are copied into EVP_PKEY_CTX
 
 This time, I really do hope to get some feedback. Reviewing this won't
 be wasted time, I'm happy to improve the code until it is ready for
 merging.
 
 As such pss certificates are now being deployed by the millions for
 digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
 support them.
 

As has been indicated the PSS ASN1 module is incorrect. Does that
actually verify PSS signatures correctly with non-default algorithms?
I'd expect ASN1 parsing errors.

A quick look through (I'm not short of things to do at the moment
alas...) suggests ctrl return codes aren't checked properly in a number
of places.

I also find the lack of any use of the PSS OID as rather strange. The
specifications I've seen should require it is at least checked.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-02-07 Thread Martin Kaiser via RT 

Dear OpenSSL team and all,

finally, here's my patch (against today's 1.1 snapshot) for verification
of X.509 certificates using an RSASSA-PSS signature. I believe it is
fairly complete in terms of checking parameters.

The patch follows the idea that I outlined in previous posts

- two new ASN.1 objects for pss, mgf1
- in obj_xref.txt, pss uses digest undef
- verify routine has to determine the digest by itself
- ASN1_item_verify() uses EVP_DigestVerify... API
- rsa_st gets two new elements
- param_decode method for rsa parses rsa key's parameters in the
  certificate
- at verification time, pss parameters are copied into EVP_PKEY_CTX

This time, I really do hope to get some feedback. Reviewing this won't
be wasted time, I'm happy to improve the code until it is ready for
merging.

As such pss certificates are now being deployed by the millions for
digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
support them.

Best regards,

   Martin

diff --git a/crypto/asn1/a_verify.c b/crypto/asn1/a_verify.c
index d9332ee..aed0fdb 100644
--- a/crypto/asn1/a_verify.c
+++ b/crypto/asn1/a_verify.c
@@ -134,14 +134,15 @@ err:
 int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signature,
 	 void *asn, EVP_PKEY *pkey)
 	{
-	EVP_MD_CTX ctx;
-	const EVP_MD *type = NULL;
+	EVP_MD_CTX mctx;
+	const EVP_MD *md = NULL;
+
 	unsigned char *buf_in=NULL;
 	int ret= -1,inl;
 
 	int mdnid, pknid;
 
-	EVP_MD_CTX_init(ctx);
+	EVP_MD_CTX_init(mctx);
 
 	/* Convert signature OID into digest and public key OIDs */
 	if (!OBJ_find_sigid_algs(OBJ_obj2nid(a-algorithm), mdnid, pknid))
@@ -149,12 +150,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM);
 		goto err;
 		}
-	type=EVP_get_digestbynid(mdnid);
-	if (type == NULL)
-		{
-		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_MESSAGE_DIGEST_ALGORITHM);
-		goto err;
-		}
+	md=EVP_get_digestbynid(mdnid); /* md == NULL is no longer an error */
 
 	/* Check public key OID matches public key type */
 	if (EVP_PKEY_type(pknid) != pkey-ameth-pkey_id)
@@ -162,8 +158,39 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_WRONG_PUBLIC_KEY_TYPE);
 		goto err;
 		}
-
-	if (!EVP_VerifyInit_ex(ctx,type, NULL))
+   if (pkey-ameth-param_decode  a)
+  {
+  int plen;
+
+  /* this is ok for a-parameter==NULL, result is plen=0 */
+  plen = i2d_ASN1_TYPE(a-parameter, NULL);
+  if (plen  0)
+ {
+ const unsigned char *cp;
+ unsigned char *p;
+ unsigned char *pder=NULL;
+ int ok;
+
+ pder = (unsigned char *)OPENSSL_malloc(plen);
+ if (pder == NULL)
+{
+		  ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_MALLOC_FAILURE);
+		  goto err;
+}
+
+ /* call i2d_...() routines like in pem_pkey.c */
+ p = pder; 
+ plen = i2d_ASN1_TYPE(a-parameter, p);
+ cp = pder;
+
+ ok = pkey-ameth-param_decode(pkey, cp, plen);
+ OPENSSL_free(pder);
+ if (!ok)
+goto err;
+ }
+  }
+
+	if (!EVP_DigestVerifyInit(mctx, NULL,md, NULL, pkey))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -178,7 +205,7 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 		goto err;
 		}
 
-	if (!EVP_VerifyUpdate(ctx,(unsigned char *)buf_in,inl))
+	if (!EVP_DigestVerifyUpdate(mctx,(unsigned char *)buf_in,inl))
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
@@ -188,19 +215,19 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
 	OPENSSL_cleanse(buf_in,(unsigned int)inl);
 	OPENSSL_free(buf_in);
 
-	if (EVP_VerifyFinal(ctx,(unsigned char *)signature-data,
-			(unsigned int)signature-length,pkey) = 0)
+	if (EVP_DigestVerifyFinal(mctx,(unsigned char *)signature-data,
+			(unsigned int)signature-length) = 0)
 		{
 		ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ERR_R_EVP_LIB);
 		ret=0;
 		goto err;
 		}
-	/* we don't need to zero the 'ctx' because we just checked
+	/* we don't need to zero the 'mctx' because we just checked
 	 * public information */
-	/* memset(ctx,0,sizeof(ctx)); */
+	/* memset(mctx,0,sizeof(ctx)); */
 	ret=1;
 err:
-	EVP_MD_CTX_cleanup(ctx);
+	EVP_MD_CTX_cleanup(mctx);
 	return(ret);
 	}
 
diff --git a/crypto/evp/evp.h b/crypto/evp/evp.h
index 9064164..344cc03 100644
--- a/crypto/evp/evp.h
+++ b/crypto/evp/evp.h
@@ -1038,6 +1038,9 @@ void EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth,
 #define EVP_PKEY_CTRL_CMS_DECRYPT	10
 #define EVP_PKEY_CTRL_CMS_SIGN		11
 
+#define EVP_PKEY_CTRL_PARAM_SET_FROM_PKEY   20
+#define EVP_PKEY_CTRL_GET_DIGEST21
+
 #define EVP_PKEY_ALG_CTRL		0x1000
 
 
diff --git a/crypto/evp/m_sigver.c b/crypto/evp/m_sigver.c
index f0b7f95..170f6a9 100644
--- a/crypto/evp/m_sigver.c
+++ b/crypto/evp/m_sigver.c
@@ -72,19

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2009-09-21 Thread Martin Kaiser via RT 
Steve, all,

here's another idea in draft stage. Please give me feedback before I
start working out the details.


In obj_xref.txt, we define

rsassaPss   undef rsaEncryption

We add two components for pss to rsa_st

struct rsa_st   

   {

[...]
   const EVP_MD *pssDigest;  /* pointer ok or should we store the NID? */   
  
   int pssSaltlen;  

   };

and define a function to decode the parameters of the algorithm used in
the X.509 certificate

static int rsa_param_decode(EVP_PKEY *pkey, const unsigned char **pder, int 
derlen) 
   {

   /* TODO: parse and check paramters */

   if (pkey  pkey-type == EVP_PKEY_RSA)  

  {
  pkey-pkey.rsa-pssDigest = EVP_sha1();   

  pkey-pkey.rsa-pssSaltlen = 20;  

  } 

   return 1;
   }



In ASN1_item_verify(), we use the EVP_DigestVerify...() API and call
the pkey's param_decode() method


   ...
  if (pkey-ameth-param_decode)
  {
  /* TODO: pass real algorithm parameters */
  pkey-ameth-param_decode(pkey, NULL, 0);
  }
   else printf(no param_decode method defined\n);

   if (!EVP_DigestVerifyInit(mctx,pctx,md, NULL, pkey))
   ...


md may be NULL if message digest is undef is obj_xref.txt
(some low-level routines must be changed to get this result)

In do_sigver_init(), we check for type==NULL and set the pss parameters
in this case

...
 }
  else if (EVP_PKEY_sign_init(ctx-pctx) = 0)
 return 0;
  }

   if (type == NULL)
  {
  if (pkey  pkey-type == EVP_PKEY_RSA  pkey-pkey.rsa-pssDigest)
 {
 type = pkey-pkey.rsa-pssDigest;
 EVP_PKEY_CTX_set_rsa_padding(ctx-pctx, RSA_PKCS1_PSS_PADDING);
 EVP_PKEY_CTX_set_rsa_pss_saltlen(ctx-pctx, 
pkey-pkey.rsa-pssSaltlen);
 }
  else
 {
 int def_nid;
 if (EVP_PKEY_get_default_digest_nid(pkey, def_nid)  0)
type = EVP_get_digestbynid(def_nid);
 }
  }
   if (type == NULL)
  {
  EVPerr(EVP_F_DO_SIGVER_INIT, EVP_R_NO_DEFAULT_DIGEST);
...


Does this approch look ok?

Best regards,

   Martin


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2009-08-25 Thread Martin Kaiser via RT 
Steve, all,

I recently found some more time to look into this. In order to make sure
that the next attempt is in line with the rest of the code, I need some
more discussion.

  The decision table in obj_xref.txt seems to be the problem. This
  doesn't work for PSS, you can't determine the digest without parsing
  the PSS parameters.

 Yes, probably will need a special value for the digest type NID_undef
 for example which means the public key algorithm method will work out
 the digest type.

  We'll need a way to set these parameters in the EVP_PKEY_CTX or
  RSA_PKEY_CTX respectively. I've (ab)used the md_ctrl function for this.
  Could we just add a similar function pointer directly to the
  EVP_PKEY_CTX structure?


 That's what I'm considering. We pass (say) a NULL for the digest type in
 EVP_DigestVerifyInit() and call a ctrl in the associated public key
 method to let it decide which digest and parameters to use. The
 functionality isn't in EVP_DigestVerifyInit() yet it just uses a
 default digest if NULL is passed in.

The ctrl would require a  X509_ALGOR * an input so that all PSS
parameters can be determined. This struct is available only in
ASN1_item_verify(). The ctrl however could be part of EVP_PKEY_METHOD
and will be called from EVP_DigestVerifyInit(). Any idea how to pass on
the struct? 

Alternatively, I thought of adding the work out the paramters function
to EVP_PKEY_ASN1_METHOD's ctrl. It fits there as it involves some ASN1
parsing. But the resulting PSS parameters have to be stored in
RSA_PKEY_CTX. According to your last mails, this is the best place to
put the params. But it's not accessible from EVP_PKEY_ASN1_METHOD.

A third approach would be to run EVP_DigestVerifyInit() with a NULL
EVP_MD parameter (just modify it to not use a default md). When the
functions returns, we use the resulting EVP_PKEY_CTX in ASN1_item_verify
and call its pctx-pmeth-ctrl directly from ASN1_item_verify(),
supplying the X509_ALGOR * parameter.

Any thoughts what would be the best appoach?

Best regards,

   Martin


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2009-06-23 Thread Stephen Henson via RT 
 [li...@kaiser.cx - Mon Jun 22 22:13:42 2009]:
 
 Steve, all,
 
  The new pkey API was designed to avoid tieing digests to signature
  algorithms (e.g. sha1 can now be used to handle RSA and DSA signatures).
 
 i.e. you're going to remove the pkey_type field in the EVP_MD structure?
 

Well that can stay for compatibility reasons. The actual link was that
before 1.0.0 you could only sign using EVP_sha1() with RSA keys, DSA
keys needed a bogus EVP_dss1() clone digest. Similarly for other
digests and public key algorithms needed this stuff. There were horrible
hacks all over the place to switch to the correct bogus digest type.

That's gone now.

  Having looked through the API and standards it seems this can't be
  avoided without some extensions to the EVP_PKEY API.
 
 Some unsorted thoughts:
 
 RSA_PKEY_CTX already contains the required fields to store some of the PSS
 parameters. The mask generation function and its parameters are missing.
 The low-level routines have MGF1 hard-coded, the digest for MGF1 must be
 the same as for the entire PSS. This is not a big limitation.
 
 An RSA key in an X.509 certificate looks exactly the same, no matter if
 the signature is PKCSv1.5 or PSS.
 

Well there is also a PSS key type which is RSA+restrictions defined in
PKCS#1 2.0. That's an RSA key that can *only* be used with PSS.

 The decision table in obj_xref.txt seems to be the problem. This doesn't
 work for PSS, you can't determine the digest without parsing the PSS
 parameters.
 

Yes, probably will need a special value for the digest type NID_undef
for example which means the public key algorithm method will work out
the digest type.

 We'll need a way to set these parameters in the EVP_PKEY_CTX or
 RSA_PKEY_CTX respectively. I've (ab)used the md_ctrl function for this.
 Could we just add a similar function pointer directly to the
 EVP_PKEY_CTX structure?
 

That's what I'm considering. We pass (say) a NULL for the digest type in
EVP_DigestVerifyInit() and call a ctrl in the associated public key
method to let it decide which digest and parameters to use. The
functionality isn't in EVP_DigestVerifyInit() yet it just uses a
default digest if NULL is passed in.

  Do you have some examples of certificates signed with PSS? They would be
  useful for testing purposes.
 
 I've uploaded sample certificates to
 
 http://www.kaiser.cx/x509Pss.html
 

Thanks.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2009-06-09 Thread Stephen Henson via RT 
 [li...@kaiser.cx - Mon Jun 08 10:46:29 2009]:
 
 
 The attached patch against openssl-SNAP-20090607 adds support for X.509
 certificates that contain an RSASSA-PSS signature (see  PKCS1 #2.1 and
 RFC 4055).
 
 At the moment, only verification is supported, PSS parameters must be
 the default ones (either omitted or coded explicitly).
 
 The main idea of the patch is to use a new EVP_MD for sha1 coupled to
 PSS, see my mail from 1st of June (20090601112625.ga3...@kaiser.cx).
 

The new pkey API was designed to avoid tieing digests to signature
algorithms (e.g. sha1 can now be used to handle RSA and DSA signatures).
Having looked through the API and standards it seems this can't be
avoided without some extensions to the EVP_PKEY API.

I'll look into how that could be done when I'm not snowed under with
other tasks.

Do you have some examples of certificates signed with PSS? They would be
useful for testing purposes.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org