Subject: [Trans] Drop RSA PKCS#1 1.5 signatures; maybe replace with RSA PSS

From: Brian Smith <[email-masked]>
Date: Fri, 12 May 2017 08:51:38 -1000

Hi,

PKCS#1 1.5 signatures are obsolete. New specifications should not
mandate support for them.

RSA signatures in general are difficult for some devices to process
due to their large size. It would be frustrating to have used a pure
ECC infrastructure with no RSA involved at all, only to need to
implement RSA for the purpose of verifying signatures from logs. Thus
I think the group should consider dropping any mention of RSA
signatures from section 10.4.so that log clients do not have to
implement RSA.

If it really is important to have RSA signatures, then RSA PSS should
be used instead. In particular, it would be good to require the same
restricted form specified for TLS, where the same digest algorithm
must be used for all parts of the signature. Note that RSA PSS can be
made deterministic by using a fixed salt, and most implementations of
RSA PSS seem to support fixed salts if the salt length is set to zero.
As mentioned in the RSA PSS specification, PSS signatures are more
secure than PKCS#1 1.5 signatures even with a zero-length salt.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Richard Barnes <[email-masked]>
Date: Fri, 12 May 2017 15:18:22 -0400

+1

On Fri, May 12, 2017 at 2:51 PM, Brian Smith <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Eran Messeri <[email-masked]>
Date: Mon, 22 May 2017 11:14:25 +0100

+1 for switching to RSA PSS.
I don't have any insight into why RSA was originally in 6962, so can't
argue strongly in favour of keeping it.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 24 May 2017 19:42:44 +0100

> argue strongly in favour of keeping it.

I think RSA PKCS#1 v1.5 was permitted by RFC6962 simply because the 
authors believed (and were proven correct) that some log operators might 
not be able to use ECDSA.

I'm in favour of dropping RSA PKCS#1 v1.5 from 6962-bis.  In 2017, it's 
not unreasonable to expect all log operators to be able to use ECDSA.

I'm _not_ in favour of adding RSA PSS, for the reasons Brian mentioned...
   "RSA signatures in general are difficult for some devices to process
    due to their large size. It would be frustrating to have used a pure
    ECC infrastructure with no RSA involved at all, only to need to
    implement RSA for the purpose of verifying signatures from logs."
...and because I'm pretty sure that, today, ECDSA is supported more 
widely (by deployed OSes and crypto toolkits) than RSA PSS.

> On Fri, May 12, 2017 at 8:18 PM, Richard Barnes <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     +1
> 
> 
>     On Fri, May 12, 2017 at 2:51 PM, Brian Smith <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi,
> 
>         signatures from section 10.4.so <http://10.4.so> that log
>         clients do not have to
>         implement RSA.
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/trans>
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/trans>
> 
> 
> 
> 

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.