Archive

On Wed, Nov 21, 2018 at 1:50 PM Martin Thomson <martin.thomson@gmail.com>;
wrote:

> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here.  Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivalent to an absent signature_algorithms
> extension (Section 7.4.1.4.1)
>
> The text on CertificateRequest is less clear about what to do.  That's
> understandable because it doesn't have to deal with the value being
> absent because it's not optional.  All we have to go on is this from
> Section 7.4.8:
>
>    The hash and signature algorithms used in the signature MUST be
>    one of those present in the supported_signature_algorithms field
>    of the CertificateRequest message.
>
> We think that treating an empty supported_signature_algorithms field
> as an error is the best response and plan to implement that change.
> We'll send a fatal alert if we receive one.
>

Yes, I believe this is the right approach.

-Ekr

> This is consistent with our handling of the signature_algorithms
> extension, where we treat an empty list as a failure.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2