This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Certificate-based Authentication
Certificate-based Authentication

Version management

Difference between version and

At line 1 added 32 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop