On Mon, Oct 17, 2016 at 03:18:34PM -0400, Dave Garrett wrote:
> On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote:
> > > %%% Authentication Messages
> >
> > > If sent by a server, the signature algorithm MUST be one offered in the
> > > client's "signature_algorithms" extension unless no valid certificate
> > > chain can be
> > > produced without unsupported algorithms (see {{signature-algorithms}}).
> >
> > This is seemingly about server signatures. In that context, an
> > unknown algorithm has absolutely no chance of working.
>
> This came up in a discussion a while back and we decided to allow
> unsupported algorithms as a last-ditch fall-back. Opportunistic
> encryption might not care and there are systems that may trust
> certs as a whole, not caring about the signatures. The end result
> is that the client should be tasked with making the decision to
> accept or reject, not the server. Also can be helpful for debugging.
The only possible way stuff like this is going to work is for the
client either ignores Certificate/CertificateVerify entierely (can't
trust the certificate via any method) or if the client has serious
security bug.
While e.g. trusting the server by SPKI does bypass any and all
signatures in certificates, it does not bypass this server signature.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
