- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Mon, 9 Apr 2018 20:25:53 +0300
- To: Jeffrey Yasskin <jyasskin@chromium.org>
- Cc: Yoav Weiss <yoav@yoav.ws>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Apr 09, 2018 at 05:00:28PM +0000, Jeffrey Yasskin wrote: > 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? I do not like that very much... One slightly less bad one would be require certificate that is considered ECDSA-type (TLS_ECDHE_ECDSA_WITH_*) in TLS 1.2 (which includes EdDSA certificates). Of course, that would be somewhat complicated rule. -Ilari
Received on Monday, 9 April 2018 17:26:24 UTC