<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-911E9F7E-D0AD-55EC-A3F4-1D427F803780" xml:lang="en"><title>Certificates</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>A certificate binds a public key to a certain individual/entity. This is

usually done using digital signatures: if a certificate bearing a public key

and an individual's name is signed with a key pair which you already trust,

then you can rest assure that the public key in the certificate really does

belong to the individual named in the certificate. </p>

<p>Different standards using Public Key Cryptography employ different models

for using certificates to establish trust. Such a model, encompassing data

structures, rules for their use, and users of them, may be referred to as

a Public Key Infrastructure (PKI). SSL, TLS and S/MIME all use X.509 v.3 certificates,

and a hierarchical PKI in which users are certified by Certification Authorities. </p>

<p>All data which appear in the interface between the Symbian platform and

the rest of the world need a transport encoding, and it is in this form that

they are sent and received. The transport encoding for X.509 data structures

is DER encoded ASN.1. </p>

<p><b>Certification Authorities </b> </p>

<p>Certification Authorities (CAs) are trusted third parties which perform

the following functions in the PKIX public key infrastructure: </p>

<ul>

<li id="GUID-9C43CBBB-EB93-5C63-B594-7469DDE13DCA"><p>provide trusted 'root'

certificates to users (End Entities), by supplying them with the CA's public

key </p> </li>

<li id="GUID-B6F5E212-0DAF-5D3B-B46A-D890815738FF"><p>certifying End Entities:

checking that they are who they say they are, and generating certificates

for them. The certified End Entity is the <b>subject</b> of the certificate:

the CA is the <b>issuer</b>  </p> </li>

<li id="GUID-D2C8D180-66D6-52CF-8F1F-F8CC43ED3E5C"><p>supporting certificate

revocation and revocation checking: if an End Entity suspects that their key

has been compromised, they contact the Certification Authority which issued

it. CAs publish lists of revoked certificates (known as Certificate Revocation

Lists) at regular intervals, which End Entities can use to check that certificates

sent to them have not been revoked </p> </li>

<li id="GUID-92E8639C-E89E-5663-9766-D677EE837D18"><p>publishing certificates:

the most likely place for this is an LDAP directory, since X.509 certificates

identify their subjects and issuers by describing a path through an X.500

directory </p> </li>

</ul>

</conbody></concept>