[Edit: somehow I managed to post this comment on the wrong PR! - these are related to WPA3-SAE (#293), where I have noted the same open issues. Sorry!]

I am dusting off my 75%-complete PR for adding this to the specification, and have a small number of things to resolve:

1. Key formats. The Password token key is expected to be stored and used - there is no WPA3-related use case to export or import these items. (This key is constructed via derivation from the shared password, for later use in the PAKE operation). I plan to define the import/export format as implementation-specific.

   We could instead make export/import invalid, or define the format (as being the same as the public key of the cyclic group (ECC or FFDH) for which the password token is computed.

2. Key exchange (commit) phase inputs and outputs. WPA3-SAE exchanges a scalar (integer modulo group prime) and a group element during the first part of the exchange. These are packaged in separate fields within the commit messages.

   To align with J-PAKE, thecommit-scalar andCOMMIT-ELEMENT values should require two calls to the pake output and input functions. The scalar would need a new step type value, e.g.PSA_PAKE_STEP_COMMIT_VALUE, but the ELEMENT could reuse the existingPSA_PAKE_STEP_KEY_SHARE, with a small caveat.

   The group element in the WPA3-SAE commit message is formatted very similarly to the cyclic group public key format. For FFDH it is the same. For ECC the element format is the concatenation of the x and y coordinates encoded as non-truncated big-endian integers, which is the same as the uncompressed Weierstrass public key in SEC1, but without the`0x04` prefix octet. The documentation forPSA_PAKE_STEP_KEY_SHARE currently says that the input/output format is the same as the public key format. We could leave as is (and force applications to add/remove the`0x04` prefix); make the format of this step dependent on the PAKE algorithm (and remove the prefix for WPA3-SAE); or add a new PAKE step for the WPA3-SAECOMMIT-ELEMENT.

   An entirely different approach would be to encode bothcommit-scalar andCOMMIT-ELEMENT in a single input/output step, and have the application split these on output, or concatenate on input when processing the WPA3-SAE 802.11 frames.

3. Ordering: itseems that the commitment outputs and inputs could occur in any order (e.g. the peer values can be input before extracting the commitment outputs); likewise for the confirmation values (although the counter has to be set prior to output of the confirmation value); the salt could in theory be input at any time before the confirmation phase starts; and the key id can be output at any time after the commitment phase is complete. However, requiring flexibility might be costly for an implementation, but demanding a rigid ordering may also add costs for an application and unnecessary validation overheads in an implementation. Is there a sweet spot?

[Edit by@athoelke: this response also belongs in#293 as it relates to the API definition for WPA3-SAE]

I am dusting off my 75%-complete PR for adding this to the specification, and have a small number of things to resolve:

1. Key formats. The Password token key is expected to be stored and used - there is no WPA3-related use case to export or import these items. (This key is constructed via derivation from the shared password, for later use in the PAKE operation). I plan to define the import/export format as implementation-specific.
   We could instead make export/import invalid, or define the format (as being the same as the public key of the cyclic group (ECC or FFDH) for which the password token is computed.

An implementation specific import/export format is problematic because the standard export format is also the standard key format used by the driver.
Key import/export is needed for testing. Without import/export it is impossible to use known answer tests to validate the algorithms.
We would prefer to use a point format without the leading 0x04 for ECC keys to keep it aligned with the format used in the Commit step.

2. Key exchange (commit) phase inputs and outputs. WPA3-SAE exchanges a scalar (integer modulo group prime) and a group element during the first part of the exchange. These are packaged in separate fields within the commit messages.
   To align with J-PAKE, thecommit-scalar andCOMMIT-ELEMENT values should require two calls to the pake output and input functions. The scalar would need a new step type value, e.g.PSA_PAKE_STEP_COMMIT_VALUE, but the ELEMENT could reuse the existingPSA_PAKE_STEP_KEY_SHARE, with a small caveat.
   The group element in the WPA3-SAE commit message is formatted very similarly to the cyclic group public key format. For FFDH it is the same. For ECC the element format is the concatenation of the x and y coordinates encoded as non-truncated big-endian integers, which is the same as the uncompressed Weierstrass public key in SEC1, but without the`0x04` prefix octet. The documentation forPSA_PAKE_STEP_KEY_SHARE currently says that the input/output format is the same as the public key format. We could leave as is (and force applications to add/remove the`0x04` prefix); make the format of this step dependent on the PAKE algorithm (and remove the prefix for WPA3-SAE); or add a new PAKE step for the WPA3-SAECOMMIT-ELEMENT.
   An entirely different approach would be to encode bothcommit-scalar andCOMMIT-ELEMENT in a single input/output step, and have the application split these on output, or concatenate on input when processing the WPA3-SAE 802.11 frames.

We would like to use the approach with the scalar and the element (without the 0x04) in a single input/output step. There is no need for splitting or concatenation in the application, the combination of the two can be copied directly to/from the WPA3-SAE 802.11 frame.
An additional question is whether we should add the "Finite Cyclic Group" field in front of the scalar and element fields. This could as well be added by the application but we would prefer to include it to make the data more self consistent.

A similar question arises in the Confirm step: should we include the Send-Confirm field in front of the Confirm value?
Including it makes the handling of the input step easier because all relevant values are in the input data. For the output however, a separate input step is needed for the Send-Confirm value because it must be provided by the application.
If the Send-Confirm field is not included in the Confirm step. it must be provided in a separate Send-Confirm input step for the both the Confirm input and output steps because it is needed for the calculation of the Confirm value.
We would prefer to include the Send-Confirm values.

3. Ordering: itseems that the commitment outputs and inputs could occur in any order (e.g. the peer values can be input before extracting the commitment outputs); likewise for the confirmation values (although the counter has to be set prior to output of the confirmation value); the salt could in theory be input at any time before the confirmation phase starts; and the key id can be output at any time after the commitment phase is complete. However, requiring flexibility might be costly for an implementation, but demanding a rigid ordering may also add costs for an application and unnecessary validation overheads in an implementation. Is there a sweet spot?

To keep the implementation simple, we currently use the following rules:
After psa_pake_setup(), psa_pake_set_user(), and psa_pake_set_peer() there is a Commit phase with all Commit inputs and outputs in any order.
Then there is a Confirm phase with all other steps (Salt, Send-Confirm, Confirm, KeyId) in any order except that Salt and Send-Confirm must be supplied before the corresponding Confirm.
Providing Salt or Send-Confirm before or during the Commit phase does not bring any advantage for the application.
Be aware that the Confirm steps may be used multiple times with varying Send-Confirm values.