On 11/09/2017 19:42, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed to > reflect > both the capabilities of your TLS stack and the capabilities of your PKI > verifier [0]. So, yes, if you advertise this it is supposed to work. So, > ideally > we would just say that it's as Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both places > 2. Invent a new extension whose semantics are "if present, this tells you what > the PKI validator accepts, otherwise look at signature schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe it's right > anyway... >
It's rather more than just certificate signatures. The problem here is that there is no way to indicate an implementation supports rsaEncryption keys but not RSASSA-PSS keys and the current draft requires that implementations support both AFAICS. RSASSA-PSS keys are pretty rare at the moment. There are some complications involved with supporting them not present with other key types: more complex parameter sets and key restrictions for example. Implementors might feel (despite what the draft says) that the added complexity is not justified because no one will ever want to use RSASSA-PSS keys. At the same time if important implementations abort the handshake when they see an RSASSA-PSS key then this is a strong reason for a server to not deploy RSASSA-PSS keys: it will cause interoperability issues. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
