[gnutls-help] gnutls_ext_register

[Ali Blaybel]

Hello really i need your help, thank you anywayIf 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 OverviewIn 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 payloadis 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 eitherdoes 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 discretioneither 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 generatedaccording to the cipher algorithm selected by the server in the ServerHello.cipher_suite. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150507/f422bc41/attachment-0001.html>