Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[Hubert Kario <[e-mail]>]

On Saturday 11 July 2015 17:09:27 Dave Garrett wrote:
> On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote:
> > Largely close enough.  Feel free to borrow any text from the below
> > that you find to be an improvement.
> > 
> >     ========================================
> >     
> >     Whenever possible, all certificates provided by the server
> >     SHOULD be signed by a hash/signature algorithm pair indicated
> >     by the client's supported algorithms extension (or the defaults
> >     assumed in its absence).  If the server cannot produce a
> >     certificate chain that is signed via only the indicated supported
> >     pairs, then it SHOULD continue the handshake by sending the
> >     client a certificate chain of its choice that may include
> >     hash/signature algoriths that are not known to be supported by
> >     the client.
> >     
> >     The public key in the leaf certificate must of course be
> >     compatible with the chosen cipher-suite, and the subsequent
> >     ServerKeyExchange message must be signed via a mutually supported
> >     hash/signature algorithm pair.
> >     
> >     If the client cannot construct a satisfactory chain using the
> >     provided certificates and decides to abort the handshake, then
> >     it MUST send an "unsupported_certificate" alert message and
> >     close the connection.
> >     
> >     ========================================
> 
> The middle bit is already in existing text above the section in question.
> 
> New version with a little rewording and a typo fix.
> 
> \/
> 
> ========================================
> All certificates provided by the server SHOULD be signed by a
> hash/signature algorithm pair indicated by the client's
> "signature_algorithms" extension (or the defaults assumed in
> its absence), where possible. If the server cannot produce a
> certificate chain that is signed only via the indicated supported
> pairs, then it SHOULD continue the handshake by sending the
> client a certificate chain of its choice that may include algorithms
> that are not known to be supported by the client. If the client
> cannot construct an acceptable chain using the provided certificates
> and decides to abort the handshake, then it MUST send an
> "unsupported_certificate" alert message and close the connection.
> ========================================

What about the cert chain offered by client to server as a response to 
Certificate Request message?

They are also under the limitation of using just the signature algorithms 
advertised as supported by server.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic