Currently, if pubKeyCredParams is not provided by the webAuthn makeCredenial request, the spec creates a pubKeyCredParams with the values ES256 and RS256.
Looking at changes in CTAP for PQ, the default algs are hardcoded into the WebAuthn spec unless RP actively overrides them.
We should consider if those are the correct defaults.
They are for interoperability, however, not so much for security anymore.
Based on P256 curve being deprecated in Suite B over 10 years ago and understanding that it will be the first PQ alg to fall (If it hasn't already), we should at least consider adding P384 to the list for authenticators starting to deprecate P256.
The more difficult choice is if we should prefer P384 in the list over P256.
Based on the latest Google paper (mostly focused on bitcoin), 1,200 logical cubits are required for P256, bumping the bitlength to P384 the number of logical qbit required almost doubles to 2,200. (Extrapolating from standard ECC quantum resource formulas (where logical qubits approx 6n) and factoring Googles 20x performance gain). That is about the same post qantum strength for P384 as RSA2048.
My minimum change would be to add P384 and perhaps one of the ML-DSA algs (ML-DSA44?).
More of a change we could/should consider is changing the priority as well.
I will do a pull request with the minimum change and we can fight it out on if and when we change the default priority.
Proposed Change
Describe your proposed change. If you have suggested text, please file a corresponding Pull Request.
Currently, if pubKeyCredParams is not provided by the webAuthn makeCredenial request, the spec creates a pubKeyCredParams with the values ES256 and RS256.
Looking at changes in CTAP for PQ, the default algs are hardcoded into the WebAuthn spec unless RP actively overrides them.
We should consider if those are the correct defaults.
They are for interoperability, however, not so much for security anymore.
Based on P256 curve being deprecated in Suite B over 10 years ago and understanding that it will be the first PQ alg to fall (If it hasn't already), we should at least consider adding P384 to the list for authenticators starting to deprecate P256.
The more difficult choice is if we should prefer P384 in the list over P256.
Based on the latest Google paper (mostly focused on bitcoin), 1,200 logical cubits are required for P256, bumping the bitlength to P384 the number of logical qbit required almost doubles to 2,200. (Extrapolating from standard ECC quantum resource formulas (where logical qubits approx 6n) and factoring Googles 20x performance gain). That is about the same post qantum strength for P384 as RSA2048.
My minimum change would be to add P384 and perhaps one of the ML-DSA algs (ML-DSA44?).
More of a change we could/should consider is changing the priority as well.
I will do a pull request with the minimum change and we can fight it out on if and when we change the default priority.
Proposed Change
Describe your proposed change. If you have suggested text, please file a corresponding Pull Request.