Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Introduction to digital certificates

By imrdkl in Technology
Sun Apr 28, 2002 at 03:49:49 AM EST
Tags: Focus On... (all tags)
Focus On...

What is a digital certificate? What does it do? Where is it kept? Can you hang them on your wall? And most importantly, why should you care? If you're working in the IT industry, or for a large security-minded company, or possibly even if you only have a bank account with internet access, then you may already have one - although you may not be completely aware of it, or how it works.

This article will give a short and simple overview of digital certificates, with some bits about what they're used for, and perhaps pique your interest enough to learn more about them. The digital certificate is a cornerstone of many Digital Id implementations which are available today, and others which are being considered, including the National ID Card. They can be very useful for increasing security, and despite what some may contend, they are probably not the dreaded mark, although I don't recommend that you have one implanted.


What is a certificate?

Since I won't be discussing digital certificates which are implanted in or tattooed on a person, we may consider the certificate purely as an electronic assertion which resides on a specific device, such as a computer, or mobile phone. The assertion can take many physical forms, such as a file, or an entry in the computer registry. The assertion is to trust.

The primary roles of Certificates

A certificate can be used in many different types of activities, but there is only one of two possible roles for all certificates. These are as follows.
  • Grantor of authority - the owner (or creator) of this type of certificate grants authority to the other type of certificates (Grantee) so that they may be used to execute the activities. A Grantor type of certificate is also called a Root or CA certificate, or sometimes an SubCA certificate.
  • Grantee of authority - this type of certificate is granted authority (signed) from the Grantor certificate. The owner (or holder) of the Grantee certificate may then use it's granted authority to execute the activities. These activities are referred to as trusted activities. The Grantee certificate may also called an end-user certificate.

Every certificate has a pair of encryption keys

Every certificate has associated with it an so-called keypair, which are usually created by the owner of the certificate. This person, or other entity, is known as the requestor of the certificate. The keys usually will have been generated via a software tool or device which is capable of such things. One of the keys in the keypair is called the public key, and is built-in to the certificate itself. The other key, called the private key is not part of the certificate. The private key is kept secure by the owner of the certificate, via encryption using passwords, or other means. The private key is only used during the time when the certificate is physically granting or executing it's authority.

This article will not attempt to address the mechanics related to encryption keys. However, there is one addition point worth mentioning here.

If you are asked (told) to accept a digital certificate for which you did not create the keys, you should consider the request carefully. If you do not make the keys which are in your certificate, then you may not have exclusive control over it.

Every certificate is unchanging

Certificates, out of necessity, are immutable. Once they are created, they cannot be changed, or renewed. They have a specific lifespan, which is assigned at the time of creation, in the case of Grantor certificates, or at the time of the signing, for Grantee certificates. When a Grantor certificate is created, we say that the creator has created an Certifying Authority, or CA. This CA then has a specified lifespan, and can grant some or all of it's specific, unchanging Authority to end-user certificates. The owner of the CA certificate also specifies the amount of time that the the end-user certificate shall have permission to execute the Authority, or "live".

Every certificate has Authority

The Authority which is granted by Grantor certificates, and received by Grantee certificates, is given in order to allow the Grantee certificate to perform one or more specific trusted activities, as already mentioned. The high-level activities which are allowed each have specific low-level requirements which must be granted in the correct combination and amount, for the end-user certificate to properly perform the activity. These specific low-level requirements are also called the attributes of a certificate. This article will not discuss the attributes which are built into a certificate. It will discuss the high-level activities which certificates are used for, to execute their Authority in a particular setting.

The authority which is built into a certificate is valuable and should be protected. Any grant, or execution of the authority built into a certificate requires both of the keys, discussed earlier. If, at any time in the life of the certificate, the Grantee or the Grantor decides for any reason that the certificate should be invalidated, the process by which this invalidation is accomplished is called revocation. When a certificate is revoked, it's effective life ends immedietly. The revocation occurs via a process which is initiated by the Grantor of the certificate's authority. Any entity which then wishes to validate the Grantee's certificate will be told that it is no longer valid.

Some High-Level activities authorized by certificates.

When considered in the realm of an computer operating system, the activities which are executed with the aid of Grantee certificates include four specific types which are interesting, among others which won't be considered in this article. These four types of end-user certificates are:
  • Server - an server certificate has been granted authority to participate in the activity of implementing an secure webserver, or other type of secure internet server. Anytime you connect your browser to a secure website, a Server certificate is executing it's authority.
  • Client - an client certificate has been granted authority to participate in an internet client-server relationship as client (with a Server). The client certificate may authenticate the person which is actively using the client machine, or it may specify characteristics of the network or machine where it is installed, or both.
  • CodeSigning - an codesigning certificate has been granted authority to permanently mark binary object code which runs on a computer. This activity entails applying a sort of permanent "seal" to the object code, so that changes can be detected in it, as well. This activity is also referred to as code signing, as inferred by the name. Note - this is not the same sort of signing that is done with an Grantor certificate.
  • Email - an email certificate has been granted authority to participate in the activity of securing email between individuals or groups. Many popular mail user agents implement secure email options with the help of Email certificates.

More on Grantor/CA certificates

At this point, one important point should be re-emphasized.
Grantor/CA certificates sign certificates, but cannot be used to execute their own authority. Only Grantee/end-user certificates can execute the Authority which is granted by Grantor certificates. Likewise, Grantee certificates cannot sign other certificates. Grantee certificates can be used to sign data and code, however.
This is an important distinction. Another article may further consider the finer points of this distinction. Root certificates are, by nature, self signed. As previously mentioned, SubCA certificates also can sign certificates. An SubCA certificate is signed by a Root certificate which is granting it's power to sign certificates, along with the one or more of the authorities previously discussed. Think of an SubCA certificate as a middleman, of sorts, who is an authorized re-distributor of some or all of the authority held by the Root. Again, more on the topic of SubCA belongs in a separate article.

Summary

There's not much that can be discussed in the realm of Digital Id without a good basic grasp what a certificate is, it's uses and authority, the risks associated with them, and at least something about their mechanics. This article is intended as a starting point only.

More information about certificates and how they're built and used, will be found in my next article. If you cant wait until then, then have a look at Digital Id World for other introductory articles. For more than you probably would ever want to know about certificates and Certifying Authorities, and the broader topic of Public Key Infrastructure take a look at the PKI Forum

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Digital certificates
o Wow! 17%
o Hmm. 24%
o Yawn. 48%
o Aak. 4%
o Nooooo! 4%

Votes: 45
Results | Other Polls

Related Links
o National ID Card
o dreaded mark
o software tool
o Digital Id World
o PKI Forum
o Also by imrdkl


Display: Sort:
Introduction to digital certificates | 11 comments (4 topical, 7 editorial, 0 hidden)
What are pants? (4.80 / 15) (#5)
by dr k on Sat Apr 27, 2002 at 04:22:35 PM EST

What are pants? What do they do? Where are they kept? Can you hang them on your wall? And most importantly, why should you care? If you're working in the IT industry, or for a large security-minded company, or possibly even if you only have a bank account with internet access, then you may already have sone - although you may not be completely aware of them, or how they work.

Every pair of pants has a pair of pant legs

Every pant leg has associated with it corresponding leg. If you try to put your left leg down the right pant leg, the pants will not function as designed.

&c, &c


Destroy all trusted users!

I like this article (3.25 / 4) (#9)
by Goatmaster on Sun Apr 28, 2002 at 03:08:29 PM EST

Answered my lingering questions about digital certs that I was too lazy to look up myself.
Thanks.


... and so the Goatmaster has spoken
Revocation - you're the doctor its so fun to play! (none / 0) (#10)
by lordpixel on Mon Apr 29, 2002 at 12:44:33 PM EST

>If, at any time in the life of the certificate, the
>Grantee or the Grantor decides for any reason that
>the certificate should be invalidated, the process
>by which this invalidation is accomplished is called
>revocation. When a certificate is revoked, it's
>effective life ends immedietly <sic>. The revocation
>occurs via a process which is initiated by the
>Grantor of the certificate's authority. Any entity
>which then wishes to validate the Grantee's
>certificate will be told that it is no longer valid.

Ah, now here's a problem the astute reader may wish to consider... its been glossed over, which I'll allow given this is supposed to be an introduction.

The trouble with this is there are only 2 ways to do it:

1/ Maintain revocation lists which tell which certificates have been cancelled...

Problem - every "exercise" of the authority must also look at the revocation lists to ensure the certificate hasn't been cancelled.

Quite apart from the huge bottleneck and performance concerns, imagine how much fun you can have trying to ensure that:

(i) no clients have bugs which cause them not to check the revocation list every time (or what if the client is malicious?)

(ii) a man in the middle can't do denial of service attacks by making it look to the client that the certificate is revoked (to name but 2 problems).

Its a little easier in the case of a certificate issued to a server, since the server can be trusted to check the revocation list, and you may be able to control where this list comes from. Its much harder if the client needs to establish a certficiate isn't invalid.

You're going to have to distribute the revocation list somehow (so you can load balance) and sign the revocation list to prove its genuine - but now the problem is recursive - how can one be sure the certificate used to sign the revocation list has not been revoked? (obv. this is a much smaller set of certificates to manage, but...)

Method 2/ maintain lists of all copies of certficates and have the CA explicitly go invalidate all of them.

Pros: certificate is invalidated, so no client can mistakenly think its still valid

Cons: see man in the middle above.

Timeliness - can you be sure all copies can be invalidated in a reasonable timeframe?

Practicality - this scheme is often proposed for use by a single computer, but how will you find all copies on the internet? Wait for Joe Sixpack to dialup to AOL then send his computer commands to revoke certificates? I think not!

(one possibility is to revoke the next time the client certificate is presented to some central server, but now you're back into the problems of method 1/)

Even on a single computer, what if a malicious client wants to prevent you from revoking the certificate?




I am the cat who walks through walls, all places and all times are alike to me.
In practice (none / 0) (#11)
by imrdkl on Mon Apr 29, 2002 at 02:54:28 PM EST

I think most of your fears are slightly overblown. However, revocation is a hard problem indeed, when considering a truly "public" CA. It becomes much more managable as scale decreases, and nearly trivial when connections are through the CA's own network. As to man in the middle... that problem goes away with certs, and cert-based connections.

X.509 and PKI becomes most difficult when you consider it on the global scale. Perhaps even unworkable.

[ Parent ]

Introduction to digital certificates | 11 comments (4 topical, 7 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!