Re: Origin Signed Responses and certificate requirements

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

> On Mon, Apr 09, 2018 at 06:25:03PM +0000, Jeffrey Yasskin wrote:
> > 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:
> > > >
> > > > > 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?
>
> Pretty much that.
>
> > 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?
>
> Well, that is pretty much the same set of certificates as used by
> TLS_ECDHE_ECDSA_WITH_* in TLS 1.2.
>
> > It sounds like you might be fine with using a non-RSA certificate as
> both a
> > TLS server certificate and package-signing certificate?
>
> Yeah, I consider RSA pretty much legacy.
>

Thanks. I have a PR implementing this at
https://github.com/WICG/webpackage/pull/179, which I'd love folks to review.

Jeffrey