Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519

["D. J. Bernstein" <[e-mail]>]

Bryan Ford writes:
> better than if there was no context parameter.

Applications that share keys are very likely to copy this parameter, for
the same reasons that they pretty much always end up copying MIME types.
The benefits you're referring to are limited to cases where applications
share keys but manage to stick _more_ information into this parameter
than they would have stuck into the message itself.

Meanwhile everyone ends up suffering through bottom-to-top complications
in the signature API. This is, in particular, a drag on auditing, and
it's going to end up taking resources away from auditing and fixing the
hard cases of cross-protocol attacks, very much the same way that a pile
of well-intentioned complications to the X.509 certificate format ended
up taking resources away from what we _need_ to do with certificates.

> in any IETF-defined protocol in the future that specifies that the
> context parameter must be “FOO”

The IETF-defined protocols can just as easily use prefixes---in fact,
more easily, because then they simply work with _all_ signature systems
rather than just systems supporting the committee API.

Nobody is objecting to having signature users coordinate message
semantics (especially if they're sharing keys!). Nobody is objecting to
having a central registry of prefixes. But this doesn't need a new API,
and there are many other reasons to object to a new API.

---Dan