Subject: [TLS] Client Request and ecdsa_sign

From: "Mehner, Carl" <[email-masked]>
Date: Sat, 14 Mar 2015 05:43:12 +0000

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.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Mar 2015 07:35:12 -0700

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 <[email-masked]> wrote:

> 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?
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>