Re: Origin Signed Responses and certificate requirements

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

> 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...
>

Thanks. Could you say a little more about why? Which specific other
certificate types do you want to be able to use before we use a v2 to
revise the cryptographic suite? Are you looking for ed25519 support, keys
with a security level higher than 128 bits, the ability to add post-quantum
algorithms, or something else?

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.
>

Or a certificate usable with "a non-legacy, non-RSA signature algorithm
accepted by TLS 1.3", which today would be ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, or ed448? Or is
there a TLS 1.2 algorithm you definitely want to use?

It sounds like you might be fine with using a non-RSA certificate as both a
TLS server certificate and package-signing certificate?

Jeffrey