Re: Origin Signed Responses and certificate requirements

On Mon, Apr 9, 2018 at 5:14 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Mon, Apr 09, 2018 at 11:54:26AM +0000, Yoav Weiss wrote:
> > Hey all,
> >
> > While reviewing the Origin Signed Responses draft, I noticed that the
> > certificate
> > requirements
> > <
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req
> >
> > section
> > requires the signing certificate to have a specific opt-in to response
> > signing while also prohibiting such certs from serving TLS connections.
> >
> > >From a deployment perspective, the second requirement means that an
> entity
> > which wants to sign packages as well as terminate TLS connections would
> > have to maintain multiple certs for each domain, which will significantly
> > increase complexity.
> >
> > I'm wondering regarding the reasoning behind that second requirement. Why
> > can't certs which opt-in to signing packages also be able to serve TLS?
> > What are the risks involved?
>
> Specifically, this is because RsaEncryption keys can be used with
> insecure static RSA key exchange that will yield a signing oracle
> if one gets it even slightly wrong. And such oracles would be very
> bad thing in context like this.
>
> In theory, this would not be needed for RSA-PSS, ECC or EdDSA
> keys. But this requirement appiles even to them in name of
> consistency.
>

Because we've switched to requiring new certificates, I've been toying with
the idea of being much stricter with the set of allowed certificate types.
Do y'all think it'd be a good idea to require that everyone using v1 of
signed exchanges use exactly one kind of certificate, say secp256r1 ECDSA?
And if we did that, could we allow them to re-use that certificate for
their TLS servers?

Jeffrey