Clarify how the verifier() in appendix B is stricter than RFC8032

[dconnolly]

1. I clarified my thinking about interoperability with EdDSA, and the identity point. The gist of it is that the interoperability which is sought in FROST is that correct FROST signatures are accepted by standard Ed25519 / Ed448 verifiers, but it does not go the other way round: standard Ed25519 and Ed448 verifiers (as per RFC 8032) may accept some signatures that a FROST verifier would reject. In other words, the verifier in appendix B is stricter, since it will reject points not in the subgroup (for both public keys and commitment points) that an RFC 8032 verifier may accept; similarly, the appendix B verifier will reject the identity point (again, both as a public key and as a signature commitment point) that are deemed acceptable by RFC 8032. This is fine! But it should be said explicitly somewhere in the draft. In all generality, and especially for consensus-based applications, it matters to be precise about what signatures are accepted and what signatures are rejected. It is still weird, though, that identity points are accepted in the Ristretto255 ciphersuite: whatever reasons required the explicit rejection of the identity in DeserializePoint() for the Ed25519/Ed448 ciphersuites should equally apply to the Ristretto255 ciphersuite. I think the identity points should be explicitly rejected in the Ristretto255 ciphersuite DeserializeElement() function.

https://mailarchive.ietf.org/arch/msg/crypto-panel/kEwszf9MDNmdgJDnuUFaIHmBYwc/

[chris-wood]

I don't think we should do anything for this. The verifier in Appendix B is not meant to be used for suites compatible with RFC8032.

[chris-wood]

Closing per the comment above.

[chris-wood]

@pornin please reopen if you disagree with this conclusion.