Should we drop support of RSA Digital Signature with SHA1 hash to honor the crypto-policy setting?

[MyOzCam]

Just an follow up to closed #810

According to RFC 5996

Mechanism                              Value
   -----------------------------------------------------------------
   RSA Digital Signature                  1
      Computed as specified in [Section 2.15](https://datatracker.ietf.org/doc/html/rfc5996#section-2.15) using an RSA private key
      with RSASSA-[PKCS1](https://datatracker.ietf.org/doc/html/rfc5996#ref-PKCS1)-v1_5 signature scheme specified in [PKCS1]
      (implementers should note that IKEv1 used a different method for
      RSA signatures).  To promote interoperability, implementations
      that support this type SHOULD support signatures that use SHA-1
      as the hash function and SHOULD use SHA-1 as the default hash
      function when generating signatures.  Implementations can use the
      certificates received from a given peer as a hint for selecting a
      mutually understood hash function for the AUTH payload signature.

      Note, however, that the hash algorithm used in the AUTH payload
      signature doesn't have to be the same as any hash algorithm(s)
      used in the certificate(s).

Sound like some current IKEv2 VPN client are still auth insist mechanism as RSA Digital Signature (Auth Method = 1) and if we change the code to honor crypto-policy then we may not to compile with the RFC standard.

Currently the work around is to allow SHA1 in crypto-policy but that just open to the entire system.

[bleve]

Note, you are referencing obsoleted rfc, current one is https://datatracker.ietf.org/doc/html/rfc7296#section-3.8

[MyOzCam]

Thanks. Seem I am outdated and this should have been solved. #822

[letoams]

On Sun, 25 Sep 2022, MyOzCam wrote: Just an follow up to closed #810 According to RFC 5699 Mechanism Value ----------------------------------------------------------------- RSA Digital Signature 1 Computed as specified in [Section 2.15](https://datatracker.ietf.org/doc/html/rfc5996#section-2.15) using an RSA private key with RSASSA-[PKCS1](https://datatracker.ietf.org/doc/html/rfc5996#ref-PKCS1)-v1_5 signature scheme specified in [PKCS1] (implementers should note that IKEv1 used a different method for RSA signatures). To promote interoperability, implementations that support this type SHOULD support signatures that use **SHA-1 as the hash function** and SHOULD use SHA-1 as the default hash function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). Sound like some current IKEv2 VPN client are still auth insist mechanism as RSA Digital Signature (Auth Method = 1) and if we change the code to honor crypto-policy then we may not to compile with the RFC standard.

Please see RFC 8247 for an update: https://www.rfc-editor.org/rfc/rfc8247 RSA Digital Signature is widely deployed and, therefore, kept for interoperability. It is expected to be downgraded in the future as its signatures are based on the older RSASSA-PKCS1-v1.5, which is no longer recommended. RSA authentication, as well as other specific authentication methods, are expected to be replaced with the generic Digital Signature method of [RFC7427]. [...] When a Digital Signature authentication method is implemented, the following recommendations are applied for hash functions: +--------+-------------+----------+---------+ | Number | Description | Status | Comment | +--------+-------------+----------+---------+ | 1 | SHA1 | MUST NOT | | Additionally, every IKEv2 implementation I know of supports SHA2. There is no good reason for allowing SHA1 anymore.