Re: [TLS] Client Request and ecdsa_sign

I believe we are going to remove this entire field and its associated
code points because it is redundant with the signature algorithms.

-Ekr

On Fri, Mar 13, 2015 at 10:43 PM, Mehner, Carl <Carl.Mehner@usaa.com> wrote:

> I created a new issue on GitHub:
> https://github.com/tlswg/tls13-spec/issues/154
>
>
> Right now it appears that ecdsa certificates are not allowed for use as
> client certificates. Should we explicitly state that they may be used in
> the Client Certificate section?
>
>
> this would add an element (ecdsa_sign(64)) to the ClientCertificateType
> enum to make it:
>
> enum {
>            rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
>            rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
>            fortezza_dms_RESERVED(20), ecdsa_sign(64), (255)
>        } ClientCertificateType;
>
>
>
> as well as a new line to the certificate_types:
>
> ecdsa_sign        a certificate containing an ECDSA key
>
>
> I suppose we could add in the ecdsa_fixed_ecdh as well... but weren't we
> trying to go pure ephemeral?
>
> If so, should we take out the other *_fixed_dh identifiers? Already the
> paragraph that starts, "For historical reasons," says those have been
> obsoleted.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>