<?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>