The client should just abort the handshake and probably send an alert like internal_error since it cannot usefully proceed.
On Tue, Sep 3, 2019 at 11:27 AM M K Saravanan <mksa...@gmail.com> wrote: > Thanks Richard for the reply. Let me rephrase my question: > > If a client encounter any error condition (e.g. does not have access to > the private key for whatever reason) in generating the signature, can it > send zero bytes in the signature field of CertificateVerify message to > indicate the error condition? Is this allowed in TLS 1.2 RFC? > > with regards, > Saravanan > > > On Tue, 3 Sep 2019 at 22:36, Richard Barnes <r...@ipv.sx> wrote: > >> I don't believe that's a valid signature according to rsa_pkcs1_sha256, >> so yeah, this is probably an error. >> --Richard >> >> On Sun, Sep 1, 2019 at 11:33 PM M K Saravanan <mksa...@gmail.com> wrote: >> >>> Hi, >>> >>> Is zero signature allowed in client CertificateVerify message (I am >>> guessing may be to indicate error condition??). I don't see any thing >>> related to zero signature in the TLS 1.2 RFC (or may be I am not looking >>> into the right section?) >>> >>> Today I saw a packet like this and server was terminating the connection >>> due to the failure of client cert auth. (because of zero signature in >>> client cert verify message). >>> >>> [image: image.png] >>> >>> Under what circumstances a client can send a zero signature in the >>> client CertificateVerify message? Is this behaviour TLS 1.2 RFC compliant? >>> >>> with regards, >>> Saravanan >>> >>> >>> >>> _______________________________________________ >>> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
