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

On 22/05/17 11:14, Eran Messeri wrote:
> +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.

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 <rlb@ipv.sx 
> <mailto:rlb@ipv.sx>> wrote:
> 
>     +1
> 
> 
>     On Fri, May 12, 2017 at 2:51 PM, Brian Smith <brian@briansmith.org
>     <mailto:brian@briansmith.org>> wrote:
> 
>         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 <http://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/
> 
>         _______________________________________________
>         Trans mailing list
>         Trans@ietf.org <mailto:Trans@ietf.org>
>         https://www.ietf.org/mailman/listinfo/trans
>         <https://www.ietf.org/mailman/listinfo/trans>
> 
> 
> 
>     _______________________________________________
>     Trans mailing list
>     Trans@ietf.org <mailto:Trans@ietf.org>
>     https://www.ietf.org/mailman/listinfo/trans
>     <https://www.ietf.org/mailman/listinfo/trans>
> 
> 
> 
> 
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> 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.