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 21:34:00 +0300
To: Jeffrey Yasskin <jyasskin@chromium.org>
Cc: Yoav Weiss <yoav@yoav.ws>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20180409183400.GA377@LK-Perkele-VII>
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.


-Ilari
Received on Monday, 9 April 2018 18:34:36 UTC

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