[gnutls-help] gnutls_ext_register

[Daniel Kahn Gillmor]

Hi Ali--

On Wed 2015-05-06 15:50:11 -0400, Ali Blaybel wrote:

> if can you give me an example of how can i use this extension
> gnutls_ext_register and if i register this extension will become build
> in in gnutls (that mean i can see this extension in all example).

I think you're asking about implementing a TLS extension in GnuTLS, but
i'm not convinced that the extension you're proposing is going to be
easy to implement with just gnutls_ext_register.

> or i need to create a client and server example like "Simple client
> example with X.509 certificate support" and "Echo server with X.509
> authentication" and only used in these examples and how can i add this
> extension in these examples
>
> please see the extension overflow below 
>
> and really thank you 
>
> Extension Overview

> In order to negotiate the use of IEEE or ETSI certificate-based
> authentication, clients MAY include an extension of type
> "accepted_and_supported_certificate_type" in the extended client
> hello.  The "extension_data" field of this extension SHALL contain a
> list of supported certificate types advertised by the client, where:
>
> enum { ieee(0), ets(1), x509(2), (255) } SupportedCertType;
> enum { ieee(0), etsi(1), x509(2), (255) } AcceptedCertType;
>
> struct {
>              SupportedClientCertType supported_certificate_types<1..2^8-1>;
>              AcceptedClientCertType accepted_certificate_types<1..2^8-1>;
> } SupportedAndAcceptedCertType;
>
> DistinguishedName certificate_authorities<0..2^16-1>;
>
> - Supported_certificate_types: A list of certificate types types that the client may support.
> - Accepted_certificate_types: A list of certificate types that the client may accept.
> - Certificate_authorities: A list of the distinguished names as described in [RFC5246].

The above rough cut looks similar to either RFC 6091 or RFC 7250.
GnuTLS already implements RFC 6091, but does not currently implement
7250, afaict.  Is this a different extension you're proposing?

Would it make more sense to just work with one of these frameworks and
try to extend the certificate type registry?


> At the end of the hello phase, the client generates the
> pre_master_secret, encrypts it under the server’s public key, and
> sends the result to the server.
>
> For servers aware of the extension described here but not wishing to
> use it, it will gracefully revert to an ordinary TLS handshake or stop
> the negotiation.
>
> Clients return a response along with their certificates by sending the
> "Certificate" message and immediately after the "ClientKeyExchange"
> message. The premaster secret is generated according to the cipher
> algorithm selected by the server in the ServerHello.cipher_suite.

The paragraphs above seem to assume that the key exchange mechanism is
coupled with the certificate selection mechanism.  What you've described
is the RSA key exchange mechanism, which is likely to go away in future
versions of TLS.

For example, TLS peers can also use (EC)DHE key exchange, coupled with a
certificate for the server, where the secret key from the certificate
signs the server's DH share in order to authenticate itself.  If this is
part of your draft TLS extension, i suggest you drop this part -- if you
want to add new forms of certificate, try to touch the rest of the
handshake as little as possible.

Regards,

      --dkg