- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Mon, 9 Apr 2018 15:14:14 +0300
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Jeffrey Yasskin <jyasskin@chromium.org>
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. -Ilari
Received on Monday, 9 April 2018 12:14:49 UTC