mikewest
Plan out future agility.
@yoavweiss asked good questions about future evolution of this spec, either adding new algorithms or parameters beyond those currently supported in the profile we've defined. We should add a section to the document sketching out the path we'd expect to take.
For algorithms, we dropped the alg parameter in #33. Yoav asked:
Does that mean we're forever locked into a single algorithm? Or is there an alternative means of changing it if needed?
Right now, we reject anything other than ed25519. There's no practical difference between that and rejecting any alg parameter, insofar as you'll need to support this format while it's still a thing browsers understand.
If we'd like to support a new algorithm, we have basically the same set of options as we had prior to #33:
- Bring back the
algparameter with a new value. - Infer the algorithm from metadata (perhaps Ed25520 public keys will be 257 bits long, perhaps we'll encode the key in some ASN.1-like format that includes an algorithm identifier).
- Define a new profile that's suitable for the new algorithm (see also https://github.com/WICG/signature-based-sri/issues/34).
I don't see any significant problem here with agility. A new scheme will need a new label, but everything flow from there: from the SRI scheme and public key to the signature construction.
My understanding is that you can continue to avoid the "alg" parameter because the integrity attribute establishes the right expectation about the choice of algorithm. An adversary cannot supply you with an Ed25520[^1] signature in place of your genuinely secure Ed25519.
[^1]: ed25519 public keys are only 255 bits long anyway. So we already deal with numbers that include fixed zero bits. Ed25520 keys would be the same size, but over a non-prime field, which might not work out :) The way you deal with that is to use Math.floor((n+7)/8) bytes and zero padding, not any fancy encoding scheme.
I agree with you that shifting the type (a la #34) is likely to be the simplest way of addressing algorithmic changes. So we're back to naming... :)
We've dealt with this by allowing (and ignoring) arbitrary parameters. Closing out the issue.