On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <steffen.fr...@siemens.com> wrote:
> Hi Erik, > > > > based on your reply my conclusion is that > > - there is no (standard compliant) way for a server to use a > SHA256 based certificate for server side authentication in cases where the > client does not provide the signature_algorithm extension > Not quite. If the client offers TLS 1.1 or below, then you simply don't know if it will accept SHA-256 and you should send whatever you have. If the client offers TLS 1.2 and no signature_algorithm extension, then you technically are forbidden from sending it a SHA-256 certificate. Note that any client which in fact supports SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it, is noncomformant. It's not clear to me how many such clients in fact exist. - clients should always use the signature algorithm extension to > ensure the server can apply a certificate with the appropriate crypt > algorithms > Yes. -Ekr > > > Best regards > > Steffen > > > > On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > > > On Mar 23, 2017, at 10:31 AM, Fries, Steffen <steffen.fr...@siemens.com> > wrote: > > > > According to TLS 1.2 section 7.4.1.4.1. a client may use the > > signature_algorithm extension to signal any combinations the > > client supports, listed in the order of preferences. > > The signature algorithm is primarily about signatures made as part > of the TLS handshake, and not so much signatures in certificates. > > > > This does not seem consistent with https://tools.ietf.org/ > rfcmarkup?doc=5246#section-7.4.2 > > > > "If the client provided a "signature_algorithms" extension, then all > certificates provided by > > the server MUST be signed by a hash/signature algorithm pair that appears > in that extension." > > > > I appreciate that there are people who feel that this rule is bad, and > > to some extent it has been relaxed in 1.3, but I think the text is > > pretty clear here. > > > > > > > If the client does not use this extension, the server must use the > > signature algorithm in combination with SHA1. > > For signing the TLS key exchange, however, it should still present > whatever certificate chain it has, even if that chain employs SHA256. > It is exceedingly unlikely these days that a client will not support > SHA256 signatures in the certificate chain. > > > > Yes, that's generally true. Though a TLS 1.2 client which does not offer > SHA-256 > > in its ClientHello but accepts SHA-256 is broken. So, this should generally > > only happen with TLS 1.1 and below. > > > > > > > > > Unfortunately the server is not allowed to use this extension, otherwise > > he could tell the client his preferences according to his security > policy. > > The protocol (as it should) lacks the additional round-trips necessary for > the server to initiate signature algorithm negotiation. > > > > I'm not sure quite what the OP Is trying to achieve here. For certificates > offered > > by the server, the client just tells you what algorithms it will accept > for no negotiation > > is needed. For certificates offered by the client, the server tells the > client > > what algorithms it will accept in the CertificateRequest. > > https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4 > > > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
