Edit algorithms to permit more general proof configuration options

[Wind4Greg]

This PR addresses issue #48. It edits the document in three sections:

• Proof Configuration (ecdsa-rdfc-2019),
• Proof Configuration (ecdsa-jcs-2019),
• Base Proof Configuration (ecdsa-sd-2023)

The changes are all similar. Instead of starting with an empty object the procedure starts with a clone of the proof options, this way any custom proof options are passed through for hashing and signing.

---

Preview | Diff

[TallTed]

Small editorial tweaks for clarity

[KDean-GS1]

I have no opinion on this PR.

[msporny]

I avoid cloning the options object because it could contain information that has nothing to do with this algorithm. At worst, it could get the implementer to implement something that allows an injection attack (from the network) of some kind. Imagine that an implementer just takes options off of the wire in a VC API call and passes it right into this algorithm. If that object is then passed to a 3rd party library that takes other options, it would allow an attacker to change runtime call parameters for that 3rd party library. To avoid this class of attack, all of the algorithms are written such that that particular type of injection attack is avoided.

[dlongley]

The cloning is what enables extensibility and makes this PR solve the issue -- without it, the issue would not be solved. I think "preventing injection attacks from the network" here would be done at the wrong layer and there is already a presumption that untrusted inputs will always be appropriately sanitized (or just rejected) before being passed to a signing library. Otherwise, an attacker could ask for anything to be signed; it doesn't matter whether the proof options are "built-ins" or extensible ones.

So, -1 to changing this; I think what is here is already the right approach for solving the issue.

[msporny]

The rewrite allows a class of injection attack that should be of concern. Let's try to mitigate that class of injection attack if possible.

@Wind4Greg is this a normative change? It looks like one. We have to track those (by labeling the PR) because ANY normative change triggers another CR round (minimum wait time 30 days). I believe we have to do one anyway for all the DI specs, just noting that normative changes are typically bad things during CR... so if we have one normative change happening, we might as well do all the ones we know about.

I'm marking this one as normative until you tell me otherwise.

[msporny]

After discussion w/ @Wind4Greg and @dlongley, I'm removing my change requests for the following reasons:

• Protecting against injection attacks should be done at a higher layer than these algorithms (it's a best practice, we don't need to repeat it here).
• The algorithm is simplified by cloning the options.