Description
Note: This is not an issue for supporting EdDSA keys in subscriber certificates, or offering an EdDSA intermediate.
See this community forum thread for more background.
It only makes sense to add this to the V2 API. The V1 API is EOL and its JWS/JWK verification is pretty haggard.
At a high-level to support EdDSA account keys we will need to:
- - Add EdDSA support to
wfe2/verify.go
, notablysigAlgorithmForKey
. - - Split
goodkey
somehow to support vetting account keys differently than CSR keys. - - Add EdDSA support to
goodkey
.
This work would need to be done with a particular eye towards anywhere we might need to verify EdDSA public key parameters above and beyond what may be done by go-jose
. Similarly it may be prudent to check what linting zlint
,certlint
, etc perform for EdDSA
subscriber keys and verify that we have represented the same checks in go-jose
or goodkey
.
Splitting goodkey
to support different rules depending on the context of the public key stands out as something somewhat risky. We need to ensure there is minimal chance that the RA or CA will end up vetting a CSR key as if it were an account key, leading to misissuance of certificates.