[gnutls-help] gnutls_ext_register

[Ali Blaybel]

Hello 

really i need your help, thank you anyway


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).

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].


If
 the TLS server is willing to accept using the extension described here,
 it selects one of the supported certificate types and one of the 
accepted certificate types and includes a certificate_authorities list 
in the extension described here. The CertificateRequest payload
is 
omitted from the response. The same extension type and structure will be
 used for the server’s response to the extension described here. Note 
that a server MAY send no certificate types if it either
does not 
have an appropriate certificate to send in response to the extension 
defined here or it wishes to authenticate the client using other 
authentication methods. The client MAY at its discretion
either continue the handshake, or respond with a fatal handshake_failure alert.


The
 end-entity certificate’s public key (and associated restrictions) has 
to be compatible with the certificate types listed in extension 
described here.

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. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150506/5bb07eea/attachment.html>