W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Origin Signed Responses and certificate requirements

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>
Message-ID: <20180409172553.GA32410@LK-Perkele-VII>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC