Planning for Directory Services in Public Key Infrastructures

0.1 MB·English

by  V. Karatsiolis

Planning for Directory Services in Public Key
Infrastructures
5
0
VangelisKaratsiolis
0
TechnischeUniversita¨tDarmstadt,
2
DarmstadtCentreforITSecurity
n
Hochschulstr.10,64289Darmstadt,Germany
a
J [email protected]–darmstadt.de

3
1 MarcusLippert,AlexanderWiesmaier
TechnischeUniversita¨tDarmstadt,

]
DepartmentofComputerScience,
R
Hochschulstr.10,64289Darmstadt,Germany
C
mal,[email protected]–darmstadt.de
.
s
c
[

Abstract:Inthispaperweprovideaguideforpublickeyinfrastructuredesignersand
2
administrators when planning for directory services. We concentrate on the LDAP
v
directories and how they can be used to successfully publish PKI information. We
8
analysetheiravailablemechanismsandproposeabestpracticeguideforuseinPKI.
6
WethentakealookintotheGermanSignatureActandOrdinanceanddiscusstheir
0
partasfarasdirectoriesconcerning. Finally,wetranslatethosetotheLDAPdirecto-
1
riespractices.
1
4
0
/
s 1 Introduction
c
:
v
Public key infrastructures (PKIs) play a significant role in securing today’s communi-
i
X cation. Entities use certificates that enable security mechanisms like confidentiality, in-
r tegrity,non–repudiationandauthenticity.Therearetwospecificationsforsuchcertificates,
a
namelythe X.509[IT97] andthe PKIX [HPFS02]. The firstspecification gaveits name
tothesecertificateswhicharecalledX.509certificates. ThegoalofX.509wastoenable
authenticationmechanismsfordirectories[IT97,Sec.1]. ButX.509certificatesareused
today in various cases of internet security, for example in S/MIME to secure electronic
mail[Ram04].
X.509 certificates are issued by a certification authority (CA) and they are public docu-
ments. This fact suggeststhat they should be publishedin a public directory. The most
commonly used directories for this purpose are based on LDAP [HM02]. LDAP direc-
toriesareusedasthecentralplaceinaPKI,wherecertificatesandassociatedrevocation
information,intheformofcertificaterevocationlists(CRLs),arestoredandcanbedown-
loadedfromvariousclients.
Thispaperisorganisedasfollows:InSection2,wetakealookattheuseofLDAPinPKI.
WediscussthecertificateandCRLpublishing,thesecurityfeaturesofLDAPanddifferent
issues related to the planningof LDAP to supportPKI. In Section 3, we investigate the
relationship of the German Signature Act and Ordinance to LDAP directories. We then
discuss the LDAP related practices in this electronic signature law context. Lastly, in
Section4,weconcludethepaper.
2 LDAP and PKI
LDAPdirectoriesareusedtoholdcertificatesandCRLsinordertoprovidedissemination
ofPKIinformation. ThereareothermechanismstoenablethislikeHTTPorFTP(fora
discussionsee[HP01,Chap.9]and[AL99,Chap.11]).Allthesemechanismsarescalable
andstandardised,butLDAPisthemostcommonlydeployedsolution.Manyorganisations
alreadyoperatesuchdirectories. A reportforusingMicrosoft’sActive Directory,which
supportsLDAP,alongwith PKIinthe corporateenvironmentfor300.000usersisfound
in [GSB+04]. In addition, typical clients (like email clients) already have LDAP inter-
facestoretrieveCRLsandcertificates. Nevertheless,thewaythatLDAPbehavesinsome
cases,complicatesitssupporttoPKI.Chadwick[Cha03]makesanin–depthstudyonthis
behaviour. Gutmann[Gut00] suggeststhata relationaldatabase is a better solutionthan
LDAPasfarasstoringofcertificatesandCRLsconcerning. Inthispaperweconcentrate
ontheuseofLDAP,sincethisisasolutionalreadyemployedbymanyPKIpractitioners.
OneofthemisRegTP,1theauthorityresponsiblefortheGermanrootCA,accordingto§3
oftheGermanSignatureAct2[Leg01a]. RegTPusesanLDAPdirectorytoprovidepublic
availabilityforqualifiedcertificatesas§2.12.bSigGrequires.
2.1 Storingcertificates
2.1.1 Usercertificates
Information on an LDAP directory is hierarchically organised. In Figure 1 we can see
the entry of the user CN=Alice, O=Org, C=DE. The values between the commas
arecalledrelativedistinguishednames(RDN)andthewholevalueadistinguishedname
(DN). Every entry has a relative distinguished name. If someone moves from this en-
try to the root, and adds the relative distinguished name of every entry he meets, the
distinguished name for this entry is built. Relative distinguished names are usually in
the form attribute=value but they can also be multi–valued and presented like
attribute1=value1+attribute2=value2. This representation gives the abil-
ity to create unique RDNs among siblings in the directory. For example, in the case
of certificates the issuer name and the serial number form together a unique representa-
1ItstandsforRegulierungsbeho¨rdefu¨rTelekommunikationundPost.
2WeabbreviatetheGermanSignatureActasSigGfromtheGermantermwhichisSignaturgesetz.
tion [HPFS02, Sec. 4.1.2.2]. This representation could be used on the LDAP to create
theseuniqueentriesintheformofamulti–valuedRDN.Sucharepresentationisworkin
progressattheIETF[IET].
dc=MyOrg,dc=de(cid:13)
c=DE(cid:13)
o=OrgCA(cid:13) o=Org(cid:13)
objectClass: top(cid:13)
objectClass: top(cid:13) objectClass: person(cid:13)
objectClass: pkiCA(cid:13) objectClass: pkiUser(cid:13)
objectClass:cRLDistributionPoint(cid:13) cn=MyCA(cid:13) cn=Alice(cid:13) sn: Alice(cid:13)
cn: MyCA(cid:13) cn: Alice(cid:13)
certificateRevocationList: MII…..X(cid:13) userCertificate: MII..1…..=(cid:13)
cACertificate: MII…..=(cid:13) userCertificate: MII..2…..=(cid:13)
userCertificate: MII..3…..=(cid:13)
cert1(cid:13) cert2(cid:13) cert3(cid:13)
Figure1: AuserandaCAentryinthedirectory.Beneaththeuserentry,theideaofhavingseparate
entriesforeachcertificateispresented.
EveryentryontheLDAPhasattributesandeveryattributehasonevalue,ormoreincase
ofnotsingle–valuedattributes(see[WCHK97]fordetails). Allentrieshavetheattribute
calledobjectClass.ThisattributedescribesthekindoftheentryontheLDAP.Basedonthe
objectClass attribute values, the entry can have differentproperties. Differentproperties
can be applied to the entry by extending the values of the object class. In Figure 1 the
attributes for an end–user and a CA entry are shown. Usually, but not necessarily, the
subjectdistinguishedname containedin the entry’scertificate matchesthe distinguished
name of the entry in the directory. In the end–userentry the person objectclass as well
as the pkiUser object class are present. The first one gives the entry the ability to hold
attributeslikethesurnameorthetelephonenumber. Thesecondoneenablestheentryto
holdtheuserCertificateattributewhichrepresentstheX.509certificateforthisentry.The
userCertificateattributeholdsthecertificateinitsbinaryforminthedirectory.
ThePKIdeveloperandadministratorshouldmakeacarefuldecisionontheschema(see
[WCHK97, Sec. 3] for the definition) they want to use for publishing certificates. The
solution should not make any assumptions on the currentstatus of the directory as well
as it should not be planned to support only PKI. LDAP directories can be used to hold
informationnotrelatedtoPKI.OnechoiceistousethestrongAuthenticationUserobject
class [Wah97]. The drawbackwith this approachis that this objectclass requiresthat a
certificateispresentontheentryandthereforeitcannotbeusedincaseswheretheentry
doesnotpossessanycertificates(forexample,thecertificateisremovedfromthedirectory
afteritsrevocation).Inaddition,thisobjectclassreferstotheX.509strongauthentication
mechanism and it should not be used just as a certificate container. The solution is to
usethepkiUserobjectclass[BHR99]. Thisattributeallowsbutdoesnotrequirethatthe
userCertificateattributeispresent.Thereforethepreviousdrawbackdoesnotapplyinthis
case. Lastly, the inetOrgPerson objectclass allowsthe certificate to be publishedon the
entry too. This object class may be used when the directoryis not only used to support
PKIbutotherorganisationalproceduresanddata.
2.1.2 CAcertificates
TheobjectclassesusedtoenablepublishingofCA certificatesdiffertotheonesforend
users. Therearetwochoices. ThefirstoneisthecertificationAuthority[Wah97]andthe
secondone is the pkiCA [BHR99]. The certificationAuthoritymandatesthata CRL, the
CA certificate as well as an authority revocation list3 (ARL) [IT97] must be published
onthedirectory. ButveryfewCAsissueARLsortheCArepresentedonthisnodemay
decidenottoissueCRLsitself. Therefore,thisobjectclassisnotthebestchoiceandthe
moreflexiblepkiCAshouldbeused. ThisobjectclassallowsCRLs, ARLsandCA cer-
tificatestobepublished.TheCAcertificateisrepresentedfromthecaCertificateattribute,
theX.509CAcertificateinitsbinaryencodedform. Lastly,bothobjectclassesallowthe
crossCertificatePairattribute.Thisattributerepresentstheforwardandreverse(orissued-
ToThisCAandissuedByThisCA)cross–certificatepairforcrosscertificationpurposes.
2.1.3 Certificatesearch
CertificatesinLDAParestoredasbinaryobjectsattheentryoftheircorrespondingentity.
Therefore locating the correct certificate forces the client to know this entry (probably
from an email search or the subject distinguished name), download the certificate, then
parse it and lastly examine whether this is the one it searches for or not. This process
however,delegatesthecertificatesearchtoasomekindofside–informationsearch,infact
someinformationrelatedtotheownerofthecertificateandnotthecertificateitself.
A better approach is to publish information related to the certificate, in order to enable
searchingforthisdata. ThereisaworkinprogressintheIETF[IET]thatspecifiessuch
meta–datathatarepublishedtogetherwiththecertificate.Thisworkiseasytoimplement,
sincetheattributescanbeextractedfromthecertificateandpublishedalongwithit. This
simplifiesthesearchforcertificateswithspecialattributes,sincenowonthenodetheprop-
ertiesofthecertificates(likeserialnumber,subjectDNetc.) areheldasattributesofthe
node. ThissolutiondoesnotincorporatecrosscertificatesfromoneCAtoanother(cross
certification)and futureworkshouldaddressthis problem. Anotherworkin progressin
IETF [CL] specifies special matching rules on the directory to locate the correct certifi-
cates. Thisworkismoreextensivethanthefirstonebutmoredifficulttoimplement.This
implementationmusttakeplaceatthesideoftheLDAPvendorsandclients.
3AlistassociatedwithrevocationinformationonlyforCAcertificates.
The first work proposesalso thateverycertificate will haveits own entry subordinateto
the user entry (for a simple and not detailed draw of this idea, see Figure 1). This can
helpsolvingthefollowingproblem. Whena user ownsmorethanonecertificate, thisis
arrangedin LDAP with a multi–valuedattribute, namelythe userCertificate. A problem
with thisapproacharisesifsomeonewantstolocate onlyonespecificcertificate forthis
user.Then,onemustdownloadallcertificatesandfindoutthecorrectonebysearchingfor
thecorrectcertificatelocally. Butifeverycertificatehasitsownentrythenthisproblem
doesnotapplyanymore. Amoregenericsolutiontothisproblemisanewstandardfrom
IETF [CM04] which defines a method, that enables matching of the values (and not of
the attributes which is common in LDAP) with a special filter associated only with the
values.CurrentpracticeshouldorientonthesubentriessolutionsincemostLDAPservers
and clients do not support the special matching rules and returning of matched values.
Long term planning however, should incorporate the most generic solutions which are
on the other hand vendor and client dependent. Similar solutions can be applied to CA
certificates.
All solutions discussed here, should be used carefully with regard to reliability of the
informationcontainedontheLDAPserver.Thisinformationisnotsignedinformationand
it could have been manipulatedfrom an attacker. Every client must verifythe signature
on the certificate and CRL to ensure the security of the data. Nevertheless, LDAP has
a numberof security featureswhich can be turned on to guaranteethat no unauthorised
changesoccurinthedirectory.ItcanalsothenmeetcertainrequirementsoftheSignature
ActandSignatureOrdinance[Leg01b].
2.2 Security
Various security mechanisms can be applied to LDAP directories. They address differ-
entdirectionsandthereforecovermanysecurityaspectsofanon–lineelectronicsystem.
These attractive security features make LDAP directories a perfect candidate for the di-
rectoryservicesintheSigGcontext. Firstofalltheyallowdifferentmeansofauthentica-
tion. Oneisthesimpleauthenticationwithpassword. Anotherpossibilityistocombineit
withSASL[Mye97]foradigestbasedauthentication. Foradescriptionsee[WAHM00].
Lastly,typicalTLSclientauthenticationisalsopossible.
TLS [DA99] can also be used for securing the network traffic to the LDAP server. Of
course, the server authentication is a necessary step in this protocol, and therefore the
LDAP server must authenticate itself to the clients. TLS can be used to avoid that the
passwords will travel in clear in the simple password authentication. For more on this
schemesee[HMW00].
Apart from the authentication and security mechanism, access control mechanisms are
appliedtoLDAP.Thedirectoryadministratorcansetaccesscontrollists(ACLs),inorder
to allow certain actions to definite individuals and special parts in the directory. This
schemeisverystrongandallowsgranularcontrolsconcerningpersons,actions,anddata
inthedirectory.Anapplicationoftheabovecouldbethatarevocationauthorityisableto
publishonlyCRLsonthedirectory,whilethecertificationauthority(CA)onlycertificates.
In[Cha00]and[Gre02,Chap.5]moreonthesecurityofLDAPdirectoriescanbefound.
There are several cases, in which these security mechanismsshouldbe applied. For ex-
ample,inordertoavoidthatanunauthoriseduserreplacesarevocationlistwithanolder
one,orjustremovesacertificate. AlthoughcertificatesandCRLsaresignedinformation
andthereforetheircorrectnesscanbeproved,theintegrityofthedataonthedirectoryis
veryimportantinordertopreventsuchamisuse. Inaddition,usingtheTLSmechanism
ofLDAP,theservercanauthenticateitself. Thus,thepublishingclientcancheckwhether
it publishes the information on the correct server. This ensures that the certificates and
revocationinformationarepublishedinthecorrectplace,wheretheclientsareexpecting
thisinformationtobepublished.
2.3 StoringCRLs
CRLs are stored in a special LDAP attribute called certificateRevocationList defined in
[BHR99]. Therearethreeobjectclassesthatallowthisattribute,namelythecertificatio-
nAuthority from [Wah97], the pkiCA and the cRLDistributionPoint defined in [BHR99].
ThefirstonecannotbeusedwhenindirectCRLs[HPFS02,Sec.5]areutilised,sincethe
entryonthedirectoryisnotaCAatallandnoCAcertificateshouldbepresent.Theother
twoobjectclassesallowthecertificateRevocationListattributewithoutmandatingthisor
otherattributes. InadditionthecRLDistributionPointobjectclassmandatesthecommon-
NameattributewhichgivestheabilitytobuildanentryontheLDAPwiththeCN node.
Thebestchoiceisahybridsolutionwherebothobjectclassesarepresent(notnecessarily
onthesameentry). ThepkiCAisusedthentopublishtheCA andcrosscertificatesand
thecRLDistributionPointtopublishanyrevocationinformation.
IncaseofindirectCRLsthecRLDistributionPointobjectclassistheonlychoice.TheCRL
issuerinthiscaseisnottheissuerofthecertificateandthekeyUsageonitscertificateisfor
CRLsigning. ThisCRLissuerdoesnotpossessanyCAcertificateandthepkiCAobject
classasachoicewouldbejustwrong,sinceitdenotesacertificationauthority.Inthecase
oftheGermanrootauthoritytheCRLsissuedareindirectones. Thisisanimplicationof
thespecialvaliditymodeloftheSigG.Formoreonthisvaliditymodelsee[Bau98].
In an X.509certificate there is the possibility to state inside the certificate where to find
revocationinformationaboutit. ThisisarrangedinaspecialextensioncalledcRLDistri-
butionPoints[HPFS02,Sec.4.2.1.14].Inthisextensiontheplacewhereclientscanlocate
theCRLrelatedtothiscertificateisprovided. ThiscanbeanLDAPURLand/oraHTTP
URL, among others, which implies also the mechanism used to obtain the CRL. Use of
thisextensionisrecommendedsinceitsimplifiestherevocationinformationmanagement.
TheLDAPURLfortheentryonthedirectoryinFigure1,accordingtotheformatdefined
in[HS97],is:
ldap://192.168.0.1:389/CN=MyCA,O=OrgCA,C=DE,DC=MyOrg,DC=DE?
certificateRevocationList?base?objectClass=cRLDistributionPoint
DeltaCRLscanbepublishedintheLDAPdirectory,too. Thecorrespondingattributeis
the deltaRevocationList and an additional object class that can hold this attribute is the
deltaCRL [BHR99]. The cRLDistributionPoint object class can also hold delta CRLs.
However,thewaythisinformationisarrangedintheLDAPdirectorydoesnotutilisethe
ideaofdeltaCRLs,sincethesebecomemeaningfulonlywhenthebaseCRLisalsolocated
in the directory. Everytime a delta CRL is issued a fullCRL mustbe issued, too. This
isdoneinorderforclientsthatcannothandledeltaCRLstobeabletohavethefreshest
revocationinformation. ThiswasamandatorystepinthedeprecatedPKIXspecification
forX.509certificates[HFPS99]. ThissuggeststhatthenewerCRLreplacesthebaseCRL
(it is typical that the newer CRL just overwrites the older one in the directory). This is
notaproblemiftheclientsalreadyhavethebaseCRLintheircache. Butnewclients(or
evenclientswhichwereoff–linewhenthebaseCRLwasplacedinthedirectory)haveto
workwithcompleteCRLsuntiltheyhavethechancetolocateabaseCRLinthedirectory.
Toovercomethis,thenewerCRLmustbejustaddedtothedirectoryandnotreplacethe
olderone. Inthiscase however,the clientsmustdownloadall CRLs inorderto findthe
baseCRL.InthenewerPKIXspecification[HPFS02],whenadeltaCRLispublished,it
ismandatorythatthecorrespondingbaseCRLmustbefoundinthedirectory. AnLDAP
mechanism to distinguish between the different CRLs is needed. The new scheme for
CRLsproposedinIETF[IET],willsupportthisandthereforethisproblemcanbesolved.
In this scheme every CRL is stored in its own entry, in a similar way to the certificate
proposal.
2.4 Namingplan
In order to arrange the information effectively in the hierarchical manner of an LDAP
directorythereisaproposalinRFC2377[GHSW98]. ThisRFCproposestheuseofthe
domaincomponentattributefortherootofthe directory. Domainnamesare uniqueand
hierarchical. Thereforethey can be usedin orderto provideuniquenamesin the LDAP
model.In[KWG+98]theappropriateobjectclassestoenforcethisproposalcanbefound.
IntheActiveDirectoryofMicrosoft,theuseofdomainnamesastherootofthedirectory
ismandatory[Gre02,Chap.6].ActiveDirectorymustbeinstalledandconfiguredproperly
inordertousetheintegratedCAshippedwithWindows2000Server.
2.5 OtherusesofLDAP
LDAP directories can be used of course for other purposes too. As already mentioned,
many organisations already operate LDAP directories to administrate and manage their
information. A commonLDAP use is for central authenticationpurposesin UNIX sys-
tems. In[KLW04]itisshownthatLDAPdirectoriescanbeusedforprovidingproof–of–
possessionforencryptionkeysaswellasdeliveryofsoftwarepersonalsecurityenviron-
ments(PSE).Inthoseschemestherearetwoapplicationswhichcomealong. Oneisthe
activationofcertificates. With the termactivationwe denotethe actionto makethe cer-
tificatespublicavailable. Theotherapplicationistheprivatekeyondemand,inwhichthe
usercanlocateanddownloadhisPSEwheneverhewantstouseit. Guidaetal.[GSB+04]
have used the Active Directory for the registration purposes inside the PKI, in order to
extractidentityinformationfortheissuingofcertificates.
3 Directories andthe GermanSignature Act
Qualifiedcertificatesmustbeverifiableandoptionallyavailable. Withverifiableitisim-
plied that a mechanism to determine whether this certificate exists as well to obtain in-
formationaboutitsstatusispresent. Withavailableitisimpliedthatthecertificateitself
is located in a position where everybody can find and download it. Every Certification
ServiceProvider(CSP)therefore,mustprovideadirectoryservicewherecertificatesand
associatedrevocationinformationislocated. Onecompletetechnicalsolutiontothiscon-
sistsofanOCSPserver[MAM+99]tokeepthecertificatesverifiableandanLDAPserver
tohavethecertificatesavailable.4
OCSP servers give signed answers to a client’s query about the status of the certificate.
Therearethreepossibleanswers. Thefirstoneisgood,meaningthatthecertificateisnot
revoked. Thesecondoneisrevoked,meaningthatthecertificateisrevokedandthethird
unknown,meaningthatthecertificatedoesnotexistforthisOCSPserver(itisunknownto
it). ThereforeOCSPcanbeusedtogiveinformationaboutthestatusofacertificate. The
specialextensionCertHashhasbeenspecifiedbytheISIS–MTTspecification[TT04],in
ordertoincludealsoanexistenceevidenceofthequeriedcertificate. Thisextensionholds
the hashedvalue of the certificate the clients want to verify. With this OCSP configura-
tiontheOCSPmeetstheverifiablerequirementofthelaw. Accordingto§15.2.2.bSigV,
theverificationofaqualifiedsignaturerequiresalsoa proofofexistenceofthequalified
certificate, aswellasinformationaboutitsstatus, atthesignaturecreationtime. Further
weshowhowLDAPcanbeusedandbeappropriateintheSigGcontexttoprovideavail-
ability of qualified certificates. But more mechanismscan also be employed in parallel.
A candidate for example is the HTTP store as described in [Gut00]. There is a work in
progressatIETF[IET]thatspecifiesthisscheme.Theabovediscussiondemonstratesthat
any technicalrequirementsare outside the scope of SigG. This is because the standards
andtechniquesusedtosatisfythelawaresubjecttochanges.
Accordingto §3.1SigV,nocertificatemustbepublishedbeforeitsuser isidentifiedand
acceptshisqualifiedcertificate. Thismeansthatcompliantcertificationserviceproviders
mustwaitforanactivationofthecertificatefromitsuser. Atypicalcertificationprocessin
the corporateor institution environmentusually automatesthe publishingof certificates.
Thisautomationhowever,mustnotbeperformedintheSigGcontext. Complyingimple-
mentationsshouldenableanactivationmechanismforthepublishingofcertificates. Only
aftertheuserhasacceptedhiscertificateallsignaturesthathehascalculated,eventhose
beforetheacceptance,areconsideredineffect.Whenacertificateisactivated,itshouldbe
verifiableandifitsuserrequiresit,alsoavailable. Thisimpliesthatacertificateuponac-
4ThisisthecurrentpracticeinRegTP.
tivationmustbecomeunconditionallyknowntotheOCSPbutconditionallybepublished
ontheLDAPserver.ConformingCSPsmustdistinguishbetweencertificatesthatmustbe
keptpublicandthosewhichmustnotandhavethepropermechanismtoresolvethis.
Theaboveisalsodiscussedin§5.2SigV.Thekeyownermustexplicitlyaccepthissecure
signaturecreationentityandconfirmthistotheCSP.ThenitistheCSP’stasktopublish
thecertificateinordertokeepthecertificatespubliclyavailableandverifiablebythepub-
lic (§2.12.bSigG). After the confirmationfrom the user, the CSP is obliged to keep the
certificateonthedirectoryforatleastfiveyearsafteritsexpirationyear(§4SigV).Inthe
caseofaccreditedCSPsthistimewindowisthirtyyearsafterthecertificateexpiration.
Compliantpublishingcomponentsshouldthereforecallonlyaddfunctionstothedirectory
butneverdeletefunctions.InLDAPthisistranslatedtocallingaddrequestsandnevercall
deleteormodifyrequests(forthedefinitionsee [WHK97]). Thisgivestheabilityto the
developerto ensure correctfunctioningand complianceto the directives. If any remove
action must be performed (for example after the thirty years), then this should be done
manuallyandwiththepresenceofaspecialmonitoringmechanism.Thismechanismwill
informthe administratorof hisactions. Forexample, thismechanismwill first fetchthe
certificatefromtheLDAPbeforethedeleterequest,demonstratethistotheadministrator,
who now must check whether this is the correctcertificate or not, and delete it after the
administrator’sacknowledgement.
Moreover,aspecialmechanismshouldexistthatnotifiesincaseofafailedoperation. If
an intended LDAP operationis not successful, the system must notify the administrator
for the erroneousbehaviour. The problemmust be explicitlystated, in orderto give the
administratoraclearviewofwhichstepwasnotperformed.Then,anout–of–bandmech-
anism shouldbe used to performthe unsuccessfulstep. It is clear that this out–of–band
mechanismmusthavethesamesecuritypropertiesastheregularone. Apartfromthis, a
regularbackupofthedataonthedirectorymustbeperformedbycreatingbackupfilesof
the whole directory. This can be done with the help of the LDAP data interchange for-
mat(LDIF)[Goo00]. LDIFisatextformatthatdescribesthedataonanLDAPdirectory.
Theimportanceofthedatapersistenceinthedirectoryisdepictedalsoin§15.3SigV.The
certificatepresenceaswellasrevocationinformationrelatedtoitmusthaveacontinuous
stateinthedirectory.Inaddition,inthecaseofanaccidentalerrororserioussystemcrash,
thestatusofthedirectorycanberetrievedasitwasbeforethisevent.
Accordingto§7.2SigV,ifacertificateisrevokedthisinformationmustbepublishedinthe
directory.IntheLDAPcasethisisdonebystoringtheCRL.Asinthecaseofcertificates,
it must be ensured that the CRL publication was successful and if not, special counter-
measuresmustbeenforced. IntheCRLpublishinghowever,theactivationmechanismis
notneeded. InthiscaseitisveryimportantthatassoonastheCRLisproducedfromthe
CA,5 this CRL is also published in the directory without any delay. Another difference
isthatintheCRLcaseamodifyrequestisusuallycalled,inordertoreplacetheexistent
CRLinthedirectory. ThereisnoneedtokeepallCRLsinthedirectorysincethenewest
CRLcontainsrevocationinformationofthepreviousCRLswithinthesamescope.Ifdelta
CRLsareusedhowever,atleastthebaseCRLshouldbefoundinthedirectoryandnotbe
5OrarevocationauthoritysincetheCRLsusedintheSigGcontextareindirectCRLs.
deleted.
TheaccesscontrolmechanismoftheLDAPisusefulinthiscase,inordertodistinguish
betweenaCRLandacertificatepublishing. TheACLsinthedirectorycanbeconfigured
sothataspecialcertificatepublishinguserisonlyallowedtoaddcertificates(namelythe
userCertificate attribute) and in a special path in the directory. Another user, the CRL
user, can publish only CRLs (namely the certificateRevocationListattribute). The other
security mechanisms must be used too. The TLS connection guarantees the identity of
theLDAPserverandtheclientauthenticationensurestheidentityoftheuserpublishing
data on the LDAP. Then, no unauthorised actions on the LDAP can be performed (like
removingcertificates or replacing CRLs) and moreover,publication takes place only on
thecorrectdirectory.
4 Conclusion- Future Work
We analysed the LDAP directories and their use in PKI. LDAP is a reliable technical
solutiontoaddressthePKIinformationdisseminationproblems.Wetookalookespecially
intheSigGenvironment.WediscussedaplanningforLDAP,inordertomeetthespecial
SigG requirements associated with the public availability of certificates and revocation
information. A lotofworkisinprogressattheIETFtryingtosolveproblemsrelatedto
LDAPandPKI.AgoodplanningforLDAP,promisestoprovidea successfulsupportto
PKI as well as to other organisational procedures, particularly when the new proposals
becomeastandardandincorporatedinthecurrentsolutions.
We plan to design and implement an LDAP PKI client for management of certificates,
CRLs and software PSEs. A new standard is specified in [MSNP04] which defines a
synchronisationmethodofanLDAPclientwiththeLDAPdirectory. Wewillinvestigate
howthistechniquecanbeusedtoautomaticallydownloadnewCRLsandhowcertificates
foruserswhicharealreadyinstalledlocallycanbeupdated.
Acknowledgements
ThefirstauthorthanksGeorgiosRaptisforhishelpandguidancethroughtheGermanSig-
natureAct,andMarkusRuppertfordiscussionsonmanagementproblemsinthedirectory.
References
[AL99] C.AdamsandS.Lloyd. UnderstandingPublic-KeyInfrastructure. NewRidersPub-
lishing,1999.
[Bau98] M.Baum. Gu¨ltigkeitsmodelldesSigG. DatenschutzundDatensicherheit,23(4):199–
205,1998.