!!! Overview
[{$pagename}] is an [Authentication Method] which is used with [Certificates] within a [Public Key Infrastructure]

Digital [Certificates] are vessels for [Asymmetric Key Cryptography]. 

[Certificates] are intended to solve [Key-Exchange]. Namely, the [user-agent] wants to use the server's [Public Key]. 

An [attacker] will try to make the client use the attacker's [Public Key]. So the client must have a way to make sure that it is using the right [Public Key].

In [SSL]-[TLS], the most common use of [{$pagename}], is supposed to use [X.509] which is a standard for [Certificates]. Each [Certificate] is signed by a [Certificate Authority]. 

Typically the [user-agent] inherently knows the [Public Keys] of a handful of [Certificate Authority] (these are the "[Trust Anchors]" or "[Root Certificates]"). With these [Public Keys], the client can verify the [Digital Signature] computed by a [Certificate Authority] over a [certificate] which has been issued to the server. 

!! [Authentication] By [Certificate]
With these known [Public Keys], the [Protocol Client] can verify the [Digital Signature] computed by a [Certificate Authority] over a [Certificate] which has been issued to the [Protocol Server]. 

So the [user-agent] is supposed to do the following:
* Get a [Certificate Chain] ending with the server's [Certificate]. The [Certificate] message from the server is supposed to contain, precisely, such a chain.
* Perform [Certificate Validation] of all the [Certificates] in the [Certificate Chain], which is complex and heavy (Web browsers now do it, more or less, but it is a recent development).
* Verify that the intended server name is indeed written in the server's [Certificate]. Because the client does not only want to use a validated [Public Key], it also wants to use the [Public Key] of a specific server. See [RFC 2818] for details on how this is done in a [HTTPS] context.
If a [Protocol Client] performs these processes properly, there is a High [Level Of Assurance] that the [Protocol Server] is who-he-said-he-was and is considered [Authenticated].

This process can be extended recursively: a [Certificate Authority] can issue a [Certificate] for another [Certificate Authority] (i.e. sign the certificate structure which contains the other [Certificate Authority]  name and key). 

!! [Public Key Infrastructure Weaknesses]
The certification model for [X.509] [Certificates] has often been criticized, not really on technical grounds, but rather for politico-economic reasons. The certification model for [X.509] concentrates validation power into the hands of a [few players|Registration Authority], who are not necessarily well-intentioned, or at least not always competent. Now and again, proposals for other systems are published (e.g. Convergence or [DNSSEC]) but none has gained wide acceptance (yet).

For certificate-based [user-agent] [authentication], it is entirely up to the server to decide what to do with a [user-agent] [certificate] (and also what to do with a [user-agent] who declined to send a [certificate]). 

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]