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

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

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

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

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

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    26 is DER encoded ASN.1. </p>

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

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

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

    30 <ul>

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

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

    33 key </p> </li>

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

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

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

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

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

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

    40 has been compromised, they contact the Certification Authority which issued

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

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

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

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

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

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

    47 directory </p> </li>

    48 </ul>

    49 </conbody></concept>