fix: RSA removed, according to #164 (#174)

* fix: RSA removed, according to #164 * chore: Section improved by Amir Work * chore: editorial * editorial * editorial resolve the regression * update RP solution. editorial changes. * Update docs/en/algorithms.rst Co-authored-by: Giuseppe De Marco <[email protected]> * Update docs/en/algorithms.rst Co-authored-by: Giuseppe De Marco <[email protected]> * Update docs/en/algorithms.rst Co-authored-by: Giuseppe De Marco <[email protected]> * fix: pid issuance conflicts * fix: RP solution conflicts --------- Co-authored-by: fmarino-ipzs <[email protected]> Co-authored-by: asharif1990 <[email protected]> Co-authored-by: fmarino-ipzs <[email protected]>
italia · Feb 29, 2024 · 89fb1e1 · 89fb1e1
1 parent d53303c
commit 89fb1e1
Show file tree

Hide file tree

Showing 6 changed files with 70 additions and 44 deletions.
diff --git a/docs/en/algorithms.rst b/docs/en/algorithms.rst
@@ -8,91 +8,123 @@ Cryptographic algorithms
 The following algorithms MUST be supported:
 
 .. list-table:: 
-  :widths: 20 20 20
+  :widths: 20 20 20 20
   :header-rows: 1
 
-  * - **Algorithm**
+  * - **Algorithm `alg` parameter value**
+    - **Description**
     - **Operations**
     - **References**
-  * - **RS256** 
+  * - **ES256** 
+    - Elliptic Curve Digital Signature Algorithm (ECDSA) using one of the enabled curves listed in the section below and SHA256.
     - Signature
-    - :rfc:`7518`.
-  * - **RS512**
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_, `[ETSI] <https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf>`_ .
+  * - **ES384** 
+    - Elliptic Curve Digital Signature Algorithm (ECDSA) using one of the enabled curves listed in the section below and SHA384.
     - Signature
-    - :rfc:`7518`.
-  * - **RSA-OAEP**
-    - Key Encryption
-    - :rfc:`7518`.
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_, `[ETSI] <https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf>`_ .
+  * - **ES512**
+    - Elliptic Curve Digital Signature Algorithm (ECDSA) using one of the enabled curves listed in the section below and SHA521.
+    - Signature
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_, `[ETSI] <https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf>`_ .
   * - **RSA-OAEP-256**
+    - RSA Encryption Scheme with Optimal Asymmetric Encryption Padding (OAEP) using SHA256 hash function and the MGF1 with SHA-256 mask generation function.
     - Key Encryption
-    - :rfc:`7516`.
+    - :rfc:`7516`, :rfc:`7518`.
   * - **A128CBC-HS256**
+    - AES encryption in Cipher Block Chaining mode with 128-bit Initial Vector value, plus HMAC authentication using SHA-256 and truncating HMAC to 128 bits.
     - Content Encryption 
-    - :rfc:`7516`.
+    - :rfc:`7516`, :rfc:`7518`.
   * - **A256CBC-HS512**
+    - AES encryption in Cipher Block Chaining mode with 256-bit Initial Vector value, plus HMAC authentication using SHA-512 and truncating HMAC to 256 bits.
     - Content Encryption 
-    - :rfc:`7516`.
+    - :rfc:`7516`, :rfc:`7518`.
+
+The following Elliptic Curves MUST be supported for the Elliptic Curve Digital Signature Algorithm:
+
+.. list-table:: 
+  :widths: 20 20 20 
+  :header-rows: 1
+
+  * - **Curve Family**
+    - **Short Curve Name**
+    - **References**
+  * - **Brainpool** 
+    - brainpoolP256r1, brainpoolP384r1, brainpoolP512r1.
+    - :rfc:`5639`, `[ETSI] <https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf>`_ .
+  * - **NIST**
+    - P-256, P-384, P-521
+    - `[ETSI] <https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf>`_, `[FIPS-186-4] <https://www.nist.gov/publications/digital-signature-standard-dss-2>`_, `[ISO/IEC 14888-3] <https://www.iso.org/standard/76382.html>`_.
 
 The following algorithms are RECOMMENDED to be supported:
 
 .. list-table:: 
-  :widths: 20 20 20
+  :widths: 20 20 20 20
   :header-rows: 1
 
-  * - **Algorithm**
+  * - **Algorithm `alg` parameter value**
+    - **Description**
     - **Operations**
     - **References**
-  * - **ES256** 
-    - Signature
-    - :rfc:`7518`.
-  * - **ES512**
-    - Signature
-    - :rfc:`7518`.
   * - **PS256** 
+    - RSASSA (RSA with Signature Scheme Appendix) with PSS ( Probabilistic Signature Scheme) padding using SHA256 hash function and MGF1 mask generation function with SHA-256.
     - Signature
-    - :rfc:`7518`.
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_.
+  * - **PS384**
+    - RSASSA (RSA with Signature Scheme Appendix) with PSS ( Probabilistic Signature Scheme) padding using SHA384 hash function and MGF1 mask generation function with SHA-384.
+    - Signature
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_.
   * - **PS512**
+    - RSASSA (RSA with Signature Scheme Appendix) with PSS ( Probabilistic Signature Scheme) padding using SHA512 hash function and MGF1 mask generation function with SHA-512.
     - Signature
-    - :rfc:`7518`.
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_.
   * - **ECDH-ES**
+    - Elliptic Curve Diffie-Hellman  (ECDH) Ephemeral Static key agreement using Concat Key Derivation Function (KDF). 
     - Key Encryption
     - :rfc:`7518`.
   * - **ECDH-ES+A128KW**
+    - ECDH-ES using Concat KDF and content encryption key (CEK) wrapped using AES with a key length of 128 (A128KW).
     - Key Encryption
     - :rfc:`7518`.
   * - **ECDH-ES+A256KW**
+    - ECDH-ES using Concat KDF and content encryption key (CEK) wrapped using AES with a key length of 256 (A256KW).
     - Key Encryption
     - :rfc:`7518`.
 
 The following algorithms MUST NOT be supported:
 
 .. list-table:: 
-  :widths: 20 20 20
+  :widths: 20 20 20 20
   :header-rows: 1
 
-  * - **Algorithm**
+  * - **Algorithm `alg` parameter value**
+    - **Description**
     - **Operations**
     - **References**
   * - **none** 
+    - -
     - Signature
     - :rfc:`7518`.
   * - **RSA_1_5**
+    - RSAES with PKCS1-v1_5 padding scheme. Use of this algorithm is generally not recommended.
+    - Key Encryption
+    - :rfc:`7516`, `[Security Vulnerability] <https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack>`_, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_.
+  * - **RSA-OAEP**
+    - RSA Encryption Scheme with Optimal Asymmetric Encryption Padding (OAEP) using default parameters.
     - Key Encryption
-    - :rfc:`7516`.
+    - :rfc:`7518`, `[SOG-IS] <https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf>`_.
   * - **HS256** 
+    - HMAC using SHA256.
     - Signature
     - :rfc:`7518`.
   * - **HS384** 
+    - HMAC using SHA384.
     - Signature
     - :rfc:`7518`.
   * - **HS512** 
+    - HMAC using SHA512
     - Signature
     - :rfc:`7518`.
 
-.. warning:: 
-
-  The length of the RSA keys MUST be equal to or greater than 2048 bits.
-  A length of 4096 bits is RECOMMENDED.
-
 
 
diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst
@@ -318,7 +318,7 @@ The corresponding SD-JWT for the previous data is represented as follow, as deco
 
   {
      "typ":"vc+sd-jwt",
-     "alg":"RS512",
+     "alg":"ES256",
      "kid":"d126a6a856f7724560484fa9dc59d195",
      "trust_chain" : [
       "NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",

diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst
@@ -134,7 +134,7 @@ Below a non-normative example of the PAR.
     &client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$
     &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
     &code_challenge_method=S256
-    &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KIC Jpc3MiOiAiczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo gInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNkJoZFJrcXQz IiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1...
+    &request=$SIGNED-JWT
     &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
     &client_assertion=$WIA~WIA-PoP
 
@@ -928,7 +928,7 @@ Below is a non-normative example of an Entity Configuration of a PID Provider co
 
       {
 
-        "alg": "RS256",
+        "alg": "ES256",
         "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
         "typ": "entity-statement+jwt"
 
@@ -1161,3 +1161,4 @@ Below is a non-normative example of an Entity Configuration of a PID Provider co
           }
         }
       }
+    
diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst
@@ -18,4 +18,3 @@ In this section the following flows are described:
 
 .. include:: proximity-flow.rst
 
-
diff --git a/docs/en/remote-flow.rst b/docs/en/remote-flow.rst
@@ -57,7 +57,7 @@ The details of each step shown in the previous picture are described in the tabl
   * - **13**, **14** and **15**
     - The Wallet Instance checks if the Relying Party has provided the ``request_uri_method`` within its signed Request Object. If true, the Wallet provides its metadata in the to the Relying Party. The Relying PArty produces a new signed Request Object compliant to the Wallet technical capabilities.
   * - **13**, **14**, **15**, **16**, **17**, **18**
-    - The Request Object JWS is verified by the Wallet Instance. The Wallet processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
+    - The Request Object JWS is verified by the Wallet Instance. The Wallet processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
   * - **19**, **20**
     - The Wallet Instance requests the User's consent for the release of the Credentials. The User authorizes and consents the presentation of the Credentials by selecting/deselecting the personal data to release.
   * - **21**

diff --git a/docs/en/trust.rst b/docs/en/trust.rst
@@ -186,7 +186,7 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e
 .. code-block:: text
 
     {
-        "alg": "RS256",
+        "alg": "ES256",
         "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc",
         "typ": "entity-statement+jwt"
     }
@@ -199,13 +199,7 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e
         "jwks": {
             "keys": [
                 {
-                    "kty": "RSA",
-                    "n": "3i5vV-_ ...",
-                    "e": "AQAB",
-                    "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc",
-                    "x5c": [ <X.509 Root CA certificate> ]
-                },
-                {
+
                     "kty": "EC",
                     "kid": "X2ZOMHNGSDc4ZlBrcXhMT3MzRmRZOG9Jd3o2QjZDam51cUhhUFRuOWd0WQ",
                     "crv": "P-256",
@@ -400,7 +394,7 @@ Below there is a non-normative example of an Entity Statement issued by an Accre
 .. code-block:: text
 
     {
-        "alg": "RS256",
+        "alg": "ES256",
         "kid": "em3cmnZgHIYFsQ090N6B3Op7LAAqj8rghMhxGmJstqg",
         "typ": "entity-statement+jwt"
     }