do an dich_moi

7/31/2019 do an dich_moi

1/40

Design and Implementation of LDAP Component Matching forFlexible and Secure Certificate Access in PKIThit k v trin khai thnh phn LDAP ph hp cho truy cp Certificate linh hot v aton trong PKIAbstractLightweight Directory Access Protocol (LDAP) is the predominant Internet directory access

protocol and hence so is its use in the Public Key Infrastructure (PKI). This paper presents thedesign and implementation of LDAP component matching which enhances flexibility and secuof the LDAP directory service when it is used for the PKI certificate repositories. The componmatching together with the prerequisite ASN.1 awareness enables matching against arbitrarycomponents of certificates and enables matching of composite values at the abstraction layer ounderlying ASN.1 type definition. This allows searching for certificates with matchingcomponents without the need of providing syntax specific parsing and matching routines(flexibility), without the need of extracting the certificate components and storing them intoseparate attributes which become searchable but mutable (security), and without the need of

restructuring Directory Information Tree (DIT) to support multiple certificates per subject(manageability and performance). In this paper, we describe the architecture, key data structurand the proposed methods of enhancing interoperability and performance of our componentmatching implementation in the OpenLDAP open source directory software suite. We also

propose the use of component matching in on-line certificate validation and in Web servicessecurity. Through performance evaluation of the OpenLDAP component matching, we show tour LDAP component matching implementation exhibits the same or higher performancecompared to the previous approaches.

Tm ttLightweight Directory Access Protocol (LDAP) l giao thc truy cp th mc chim u th trInternet v do n c s dng trong c s h tng kha cng khai (PKI). Trong n nytrnh by cc thit k v trin khai thnh phn ph hp LDAP trong tng cng tnh linh hv bo mt ca dch v th mc LDAP khi n c s dng cho cc kho lu tr chng th PKCc thnh phn ph hp i hi trc ht l phi c kh nng nhn bit, nhn thc v ASN.1

php kt hp i vi cc thnh phn ty ca chng th v cho php kt hp ca cc gi tr thp lp tru tng c bn ca nh ngha kiu ASN.1.. iu ny cho php tm kim chng vi cc thnh phn ph hp m khng cn phi cung cp phn tch c php c th theo thi qu

thng thng (linh hot), khng cn phi chit xut cc thnh phn giy chng th v lu trchng vo cc thuc tnh ring bit (bo mt), v khng phi sp xp li cy thng tin th m(DIT) h tr nhiu giy chng th cho mi i tng (kh nng qun l v hiu sut). Tronnghin cu ny s m t kin trc, cu trc d liu quan trng, v phng php xut nng ckh nng tng tc v hiu sut thc hin ph hp vi thnh phn ca chng ta trong b phnmm ngun m th mc OpenLDAP. xut vic s dng cc thnh phn ph hp trong xcnhn chng ch trc tuyn v bo mt dch v Web. Thng qua nh gi hiu sut ca thnh pOpenLDAP thch hp, chng ta cho thy rng thnh phn LDAP ph hp trin khai vi cmt hiu sut hoc cao hn so vi cc phng php trc .

Keywords


2/40

1 Introduction

The certificate repository in Public Key Infrastructure (PKI) is a means of distributing certificaand Certificate Revocation Lists (CRL) to end entities. It stores certificates and CRLs and provefficient access methods to them by harnessing storage means with communication mechanismThe directory technology stands out as the most befitting approach to implementing certificaterepositories because the X.509 [14] PKI has been standardized in the context of the X.500recommendations as the public key based authentication framework on the X.500 directory.Kho lu tr chng th trong c s h tng kha cng khai (PKI) l mt phng tin phn phchng th, cc danh sch thu hi chng th (CRL) n thc th cui. N lu tr cc chng thCRLs v cung phng thc truy cp hiu qu lu tr khai thc c ngha l vi c ch giaotip.Cng ngh th mc ni bt ln nh cc phng php ph hp nht trin khai kho lu tchng th v X.509 PKI c chun ha trong khun kh ca X.500 xut nh l c s thc kha cng khai trn khun kh th mc X.500.

Lightweight Directory Access Protocol (LDAP) [10] renders lightweight directory service by

providing direct mapping onto TCP/IP, simple protocol encoding, reduced number of operatioand string-based encoding of names and attribute values (hence of assertion values). Howeverthese simplifications come at a price. Because the string-based encoding in LDAP generally dnot carry the complete structure of abstract values, adding support for new syntaxes and matchrules requires ad-hoc developments of syntax parsing and matching routines. X.500 protocolsthe other hand, avoid this problem by use of ASN.1 (Abstract Syntax Notation One) [13] encorules, in particular, the Basic Encoding Rules [12].Lightweight Directory Access Protocol (LDAP) lm cho dch v th mc gn nh bng cchcp cc nh x trc tip vo TCP/IP , giao thc m ha n gin, gim s lng cc thao tc,

m ha da trn chui cc tn v cc thuc tnh . Tuy nhin, nhng s n gin ha dn nim bt cp. Bi v m ha da trn chui trong LDAP thng khng mang cu trc y nhng gi tr tru tng, h tr thm cho c php v cc quy tc mi ph hp vi yu cu c

pht trin ca vic phn tch c php v biu ph hp, trnh vn ny bng cch s dASN.1 (1 l k hiu c php tru tng) m ha cc quy tc, c th l cc quy tc m ha c bBasic Encoding RulesThough these limitations were not viewed as a significant problem during LDAPs early yearsclear that a number of directory applications, such as PKI, are significantly hampered by theselimitations. For instance, in PKI, a certificate needs to be located based upon the contents of it

components, such as serial number, issuer name, subject name, and key usage. LDAP searchoperations do not understand ASN.1 types in the definition of the certificate attribute andassertion , because attributes and assertions in LDAP are encoded in octet string with syntaxspecific encoding rules. Not only would it require exceptional effort to support matching rulessuch as certificateExactMatch and certificateMatch as defined in, that effort would have to berepeated for each matching rule introduced to match on a particular component (or set ofcomponents) of a certificate. Because of the large amount of effort each server vendor mustundertake to support each new rule, few new rules have been introduced to LDAP since itsinception. Applications had to make due with existing rulesMc d nhng hn ch ny khng c xem nh l mt vn ng k trong nhng nm uLDAP, n r rng l mt s ng dng th mc, chng hn nh PKI, b hn ch ng k bi nhgii hn ny. V d, trong PKI, mt chng ch cn c t da trn ni dung ca cc thnh p


3/40

gi tr xc nhn, bi v cc thuc tnh v gi tr xc nhn trong LDAP c m ha trong chuvi cc quy tc c php m ha c th. N khng ch c gng yu cu h tr cc quy tc php nh certificateExactMatch v certificateMatch m s n lc s phi c lp i lp li chtng quy tc ph hp vi gii thiu ph hp vi mt thnh phn c th (hoc thit lp ca thnh phn) ca mt chng ch . Do s lng ln cc n lc mi nh cung cp my ch phi thin h tr cho tng quy tc mi, vi quy tc mi c gii thiu vi LDAP k t khi rai. ng dng c lm nh cc quy tc tn ti

Foreseeing the need to be able to add new syntax and matching rules without requiring recodiserver implementations, the directory community engineered a number of extensions to LDAPaddress these limitations. The Generic String Encoding Rules (GSER) was introduced to be uin describing and implementing new LDAP string encodings. GSER produces human readablUTF-8 encoded Unicode character string which preserves the complete structure of theunderlying ASN.1 type and supports reuse of the existing LDAP string encodings. Provided than LDAP server is ASN.1 aware, i.e. it can parse values in ASN.1 encoding rules into its interrepresentation of ASN.1 value and can perform matching in that abstraction layer, it is possibl

support matching of arbitrary types without needing ad-hoc developments of parsing and matcroutines.

Nm bt c nhu cu c th thm c php mi v cc quy tc ph hp m khng cn yum ha li ca vic trin khai trn my ch, cc cng ng th mc thit k mt s phn mrng LDAP gii quyt nhng hn ch. Qui tc m ha chung (GSER) c gii thiu c s dng trong vic m t v trin khai m ha chui LDAP. GSER c th c c UTm ha chui k t Unicode , gi cu trc hon chnh c bn ASN.1 v h tr ti s dng chum ha LDAP hin hnh. Cung cp mt my ch LDAP gip nhn bit c ASN.1, tc l nth phn tch gi tr trong quy tc m ha bn trong ASN.1 thnh gi tr i din ni b ca n

c th thc hin ph hp trong lp tru tng, n c kh nng h tr ph hp ca cc loi tym khng cn cn c bit pht trin ca phn tch c php v thi quen. ph hpThe component matching [18] mechanism was also introduced to allow LDAP matching rule

be defined in terms of ASN.1. It introduces rules which allow arbitrary assertions to be madeagainst selected components values of complex data types such as certificates. For example, thcomponent matching enables matching against the selected components of certificates withouneed to define a certificate component specific matching rule and without requiring custom coimplement that matching rule for the certificate attributesCc c ch thnh phn ph hp cng c gii thiu cho php cc quy tc ph hp vi LD

c nh ngha trong iu khon ca ASN.1. N gii thiu cc quy tc cho php cc xc nh c thc hin da theo cc gi tr cc thnh phn c la chn ca cc loi d liu phtp nh chng th s. V d, thnh phn ph hp cho php kt hp i vi cc thnh phn la chn ca chng th m khng cn phi nh ngha mt quy tc ph hp thnh phn c thchng th v khng i hi m ty chnh trin khai quy tc ph hp cho cc thuc tnh chthThough the directory community saw GSER and component matching as an eloquent solutionthe LDAP syntax and matching rule limitations, there were some concerns, as most LDAP serimplementations were not ASN.1 aware, that its adoption would bemslow. To fulfill immedianeeds of PKI applications, another solution based upon attribute extraction (or datadeaggregation) has been being utilized as a practical remedy. The attribute extraction methoddecomposes a certificate into individual components and stores them into separate, searchable


4/40

a workable solution for PKI applications (and certainly not a workable general solution to thecomponent matching problem), because it introduced a number of security and management i

Mc d th mc cng ng thy GSER v thnh phn ph hp nh mt gii php hng hgii hn quy tc ph hp v c php LDAP ,c mt s lo ngi, hu ht cc trin khai trn myLDAP khng nhn bit ASN.1, n c thng qua chm. p ng nhu cu trc ca cc dng PKI, mt gii php da trn khai thc thuc tnh c s dng nh l mt bin php

phc thc t . Phng php chit xut thuc tnh phn tch tng thnh phn bn trong chng tv lu tr chng vo cc thuc tnh ring l, c th d dng tm kim c. My ch phn tchchng th (XPS) t ng ha qu trnh khai thuc tnh. Mc d phng php ny kha lpkhong trng kh nng tng tc gia LDAP v PKI, Nhng n vn c coi l khng phi lgii php kh thi cho cc ng dng PKI (v chc khng phi l mt gii php chung hon tonthi cho vn thnh phn ), bi v n a ra mt s vn an ninh v qun lIn the spring of 2004, IBM undertook an engineering effort to provide ASN.1 awareness (withGSER, BER, DER support) and component matching functionality for the OpenLDAP ProjecStand-alone LDAP Daemon (slapd), the directory server component of OpenLDAP Software

To our knowledge, this is the first implementation of the component matching technology in apure LDAP directory server (second to the View500 [29] directory server from eB2Bcom [8]which is X.500 based). This paper presents a detailed and comprehensive description of the deand implementation of the LDAP component matching for improved PKI support, extending o

previous work [19] which had described component matching in the context of WS-Security [Another contribution of this paper is that it proposes key mechanisms to improve performanceinteroperability attribute / matching rule aliasing, component indexing, and selective compocaching. This paper will also present a preliminary performance evaluation result which convius that the performance of component matching is on par with or better than those of the synta

specific parsing and attribute extraction approaches if the optimization mechanisms proposed this paper are used. This in fact provides a strong evidential answer to the debate in the PKIVo nm 2004, IBM c nhng c gng v k thut cung cp nhn thc v ASN.1 (vi htr GSER, BER, DER) v chc nng ca thnh phn ph hp cho Daemon LDAP ca d nOpenLDAP Stand-alone (slapd), cc thnh phn ca my ch th mc OpenLDAP . nng hiu bit, iu thc hin u tin ca cng ngh thnh phn ph hp trong mt my ch th mLDAP thun ty (th hai mc t eB2Bcom n my ch th View500 da trn X.500). Binghin cu trnh by mt m t chi tit v ton din v vic thit k v thc hin ca cc thn

phn ph hp LDAP h tr ci thin trong PKI, y m t thnh phn ph hp trong

khun kh ca WS-Security . Mt s ng gp ca bi nghin cu ny l xut cc c ch qtrng ci thin hiu sut v kh nng tng tc thuc tnh /quy tc kt hp cc b danh, ccthnh phn ch mc, v la chn thnh phn cho b nh m. Bi bo ny cng s trnh by kqu ca vic thc hin nh gi s b m thuyt phc chng ta rng vic thc hin cc thnh kt hp l ngang bng hoc tt hn so vi nhng phn tch c php c th v phng php ticn khai thc thuc tnh nu cc c ch ti u ha c xut trong bi bo ny c s dnTrong thc t iu ny a ra cc bng chng tr li cc cu hi cho cc cuc tranh lun trPKI


5/40

standardization community on whether the component matching technology can be implemenin LDAP directory servers timely and efficiently. This paper also discusses on the possibility ousing the component matching for CRL in order to support on-line certificate status checkingusing LDAP. It also discusses on the feasibility of using LDAP component matching for PKI Web services security

This paper is organized as follows. Section 2 introduces the interoperation of LDAP and PKI describes the deficiencies of LDAP when it is used for PKI. Section 3 describes the componenmatching technology and its use in PKI enabling secure and flexible certificate access. It alsodiscusses on the possibility of certificate validation against CRL using LDAP componentmatching. Section 4 introduces GSER (Generic String Encoding Rules) which facilitates theASN.1 awareness in LDAP when it represents the attribute and assertion values. In Section 5,

present the design and implementation of the ASN.1 awareness and the component matching the OpenLDAP directory server. Section 6 demonstrates the application of the componentmatching for PKI to the security of Web services. Section 7 shows experimental results of our

prototype implementation of the LDAP component matching and proves that the componentmatching can be accomplished without any loss in performance. Section 8 concludes the papechun ha chung v vic liu cc cng ngh thnh phn ph hp c th c thc hin trong cmy ch th mc LDAP kp thi v hiu qu . Nghin cu ny cng tho lun v kh nng sdng thnh phn ph hp cho CRL h tr kim tra trng thi chng th trc tuyn s dngLDAP. N cng tho lun v tnh kh thi ca vic s dng kt hp thnh phn LDAP cho PK

bo mt Web

Bi vit ny b cc nh sau.Phn 2 gii thiu kh nng tng tc ca LDAP v PKI v m nh

hn ch ca LDAP khi n c s dng cho PKI. Phn 3 m t cng ngh thnh phn ph hps dng n trong PKI cho php truy cp chng th an ton v linh hot . N cng tho lun vnng xc nhn chng th s vi CRL bng cc thnh phn ph hp LDAP. Phn 4 gii thiuGSER (Generic String Encoding Rules) to iu kin cho vic nng cao nhn thc ASN.1 tronLDAP khi n th hin cho cc thuc tnh v cc gi tr xc nhn. Trong Phn 5, Em trnh bythit k v trin khai thnh phn ph hp trong cc my ch th mc OpenLDAP nhn thc vASN.1 . Phn 6 Th hin ng dng ca cc thnh phn ph hp cho PKI i vi an ninh ca cdch v Web. Phn 7 cho thy kt qu thc th nghim nguyn mu v thnh phn ph hpLDAP v chng minh rng thnh phn ph hp c th c thc hin m khng c bt k tn

trong hot ng. Phn 8 kt thc bi bo co

2 LDAP in PKI

2.1 LDAP Certificate RepositoryKho lu tr chng th s

X.509 certificates and CRLs are commonly distributed by the certificate repositories. LDAPdirectories are the most versatile mechanism of implementing the certificate repositories. Figuillustrates the conceptual interoperation of four entities in PKI. In the public key registrationphase, an end entity sends its identity as well as its public key to a Registration Authority (RA


6/40

any properly authenticated LDAP client. If the issued certificate is revoked by any reason, theis responsible for revoking the certificate by publishing CRLs to the LDAP directory. LDAPdirectories serve as the central place where the end entities not only can download certificates others in order to send encrypted messages or verify digital signatures but also can be informethe latest certificate revocation information by downloading CRLs.Chng th s X509 v CRL thng c phn phi bi cc kho lu tr chng th. Th mcLDAP l c ch linh hot nht thc hin lu gi chng th.

Hnh 1 minh ha c ch vn hnh ca cc thc th trong PKI. giai on ng k kha cngkhai, thc th cui s gi nh danh cng nh cc kha cng khai ca mnh ti c quan ng

RA. Nu nh danh c xc nhn bi RA, CA s cng b chng ch cho thc th cui, v luchng th trong th mc LDAP. Sau cc chng ch c cng b c th c ly ra xc thc bi bt k client LDAP no. Nu chng ch b thu hi bi bt k l do g, CA c trcnhim thu hi chng ch bng cch pht hnh cc CRL ti thu mc LDAP. Th mc LDAP phv nh l mt trung tm ni m cc thc th cui cng khng ch ti v cc chng ch gi cthng ip c m ha hoc xc minh ch k s m cn c th c thng bo v cc thngthu hi chng ch mi nht bng cch ti CRL v.

2.2 Deficiencies of LDAP Certificate Acces:Hn ch ca LDAP trong truy cp chng tsAn end entity should be able to send a request to the LDAP cer tificate repository searching fo


7/40

CA, it will send an assertion against serialNumber and issuer components as specified in certifiExactMatch of X.509 [14]. However, the need for matching is not limited only to these twocertificate components. An end entity may want to search for certificates which belong to asubject. It may also want to restrict the scope of the search for the subjects certificates to thoshaving a specific key usage, e.g. nonRepudiation, by using the keyUsage certificate extensionBecause LDAP stores attribute and assertion values in LDAP-specific octet strings which do ngenerally preserve structural information of the underlying ASN.1 types, however, it is far frotrivial to provide this component level matching in a generic and flexible way.X.500 satisfies this demand for component level matching by allowing matching to be definethe ASN.1 layer. For instance, defines certificateExactMatch and certificateMatch matching ru

by specifying them in ASN.1 data type representations. The use of ASN.1 specifications isbeneficial in the following respects: 1) parsing and matching can be automatically accomplishfrom the given ASN.1 type specification without providing ad-hoc routines; 2) simple but

powerful matching rules are derivable from the strong expressive power of ASN.1, as exemplin the use of OPTIOANL in certificateMatch; 3) new matching rules can be easily provided byspecifying them in ASN.1.

Hn ch khi truy cp cc chng th s trong LDAPMt thc th cui s c th gi yu cu n kho lu tr chng th LDAP tm kim mt chth c gi tr ph trong cc thnh phn c th ca chng th. Mt v d c bn, khi mun lychng ch c s serial c th v pht hnh bi mt CA, n s gi xc nhn i vi cc thnh pserialNumber v t chc pht hnh theo quy nh ti chng th ExactMatch X.509 . Tuynhin,nhu cu cho s thch ng khng ch gii hn bi 2 thnh phn ca chng th ny

N cng c th mun hn ch phm vi ca vic tm kim cc chng ch ca ch th bi v m

ngi c keyUsage c th ca ring h, v d nh chng chi b, bng cch m rng keyUsachng th. Bi v LDAP lu cc thuc tnh v cc gi tr xc nhn trong chui octet LDAP-cBi v LDAP lu tr thuc tnh v cc gi tr khng nh trong chui octet LDAP-c th nhnchung khng gi thng tin cu trc c bn ca ASN.1, tuy vy, n nay n khng ng k cp mc thnh phn ph hp trong mt cch chung chung v linh hotX.500 p ng nhu cu ny cho ph hp vi cp thnh phn bng cch cho php kt hp sc nh ngha ti cc lp ASN.1.V d, nh ngha cc quy tc ph hp certificateExactMatv certificateMatch bng cch ch r chng trong kiu d liu s miu t ASN.1. Vic s dngASN.1 cho thy r l mang li li ch trong cc kha cnh sau :

phn tch v kt hp c th c thc hin t ng t c t ca ASN.1 m khng cncung cp biu chi tit; n gin nhng mnh m cc quy tc ph hp c ly ca ASN.1, nh v d in h

trong vic s dng ca OPTIOANL trong certificateMatch; Quy tc mi c th c cung cp d dng bng cch xc nh chng trong ASN.1.

The rest of this section explains how the current workarounds try to provide solution to the abmentioned interoperability gap between LDAP and PKI and introduces the component matchiapproach focusing on its advantages over the earlier workarounds.Phn cn li ca phn ny gii thch hin ti lm th no c gng gii quyt cung cp gii p


8/40


9/40

c th nhn ra s serial v tn t chc pht hnh bng cch c hai chui phn cch bng '$'.Nhc im ca phng php ny l hin nhin. N l qu tn km xc nh cc qui tc phhp vi c php c th i vi tt c cc thnh phn c th c v kt hp chng. N cng l kkhn thch ng vi cc c ch m rng nh mt chng th v cc phn m rng CRL

2.3.2 Attribute Extraction

Trch xut cc thuc tnh

To address these deficiencies, Klasen and Gietz proposed an alternative solution, based on apractical workaround that PKI administrators have been using. A set of attributes are extractedfrom the certificate and stored as simple, searchable attribute together with the certificate in anewly created entry which is subordinate to the original one. For this purpose, they defined a s30 attributes [22] for the X.509 certificate. Matching is performed on the extracted attributesexample DIT with extracted attributes is illustrated in Figure 3. DIT (a) in Figure 3 consists of

person entries under the base o=IBM,c=US each of which contains a certificate attribute. Afte

attributes are extracted, the person entry will have a new subordinate entry whose DN(Distinguished Name) becomes x509Serial=12345,cn=John Doe,o=IBM,c=US. The attributeextraction mechanism not only makes the end entitys view of a DIT different from the CAs w

published the certificates but also doubles the number of entries at minimum gii quyt nhng thiu st, Klasen v Gietz xut mt gii php thay th, da trn mt cgii quyt thc t m cc qun tr vin PKI c s dng.Mt tp hp cc thuc tnh c xut t giy chng th v c lu tr nh l thuc tnh n , c th tm kim cc thuc tnh vi chng th trong mt mc mi c to ra ph thuc vo bn gc.Vi mc ch ny, h xnh mt tp hp ca 30 thuc tnh vi chng ch X.509. Thc hin ph hp trn cc thuc t

chit xut.V d DIT vi cc thuc tnh chit xut c minh ha trong hnh 3.


10/40

Hnh 3. V d v cy thng tin th mc (DIT).

DIT (a) trong hnh 3 bao gm cc mc nhp c nhn theo c s o = IBM, c = US mt trong sc cha mt thuc tnh chng th.Sau khi cc thuc tnh c chit xut, mc nhp c nhn smt mc mi cp di c DN (Distinguished Name) tr thnh x509Serial = 12345, cn = JohnDoe, o = IBM, c = US. C ch chit xut thc thuc tnh khng ch lm cho view cc thc thcng ca ca DIT khc nhau t CA ni m cng b chng th, nhng cng tng gp i s lcc mc mc ti thiu

With the attribute extraction mechanism, performing matching against components is identica

performing matching against attributes as depicted in Figure 2 (b). Although attribute extractifacilitates matching against components of a complex attribute, it can be considered as asuboptimal approach in the following respects. First, matching is performed on the extractedattributes, not on the certificate itself. Because the contents of the extracted attributes are mutathere is non-zero chance of returning a wrong certificate to a client if the extracted attributes wmaliciously forged. It is strongly recommended for the client to verify the returned certificateagain to ensure strong security. In the server side, on the other,hand, the server administrator mensure the integrity of a certificate and the corresponding extracted attributes in order to minimthis security vulnerability. Second, when there are more than one certificates in a directory ent

one per key usage for example, it is not possible to pinpoint and return the certificate having thmatching component (i.e. key usage for example again) since the searched-for attribute is difffrom the to-be-returned attribute. The matched value control [4] does not solve this problem,

because an LDAP attribute is set of values, not sequence of values. Therefore, it is inevitable transform the DIT structure in designing a certificate DIT to avoid the need for an additionalsearching step in the client [3]. Third, the attribute extraction does not facilitate matching agaicomposite assertion value as in X.500. It is not possible to support a flexible matching as in XcertificateMatch without making LDAP directory servers ASN.1 awareVi c ch khai thc thuc tnh,kh nng trin khai thc hin ph hp i vi cc thnh phncch chnh xc c trin khai ph hp i vi cc thuc tnh nh m t trong hnh 2 (b). Mcvic chit xut thuc tnh i vi cc thnh phn ca mt thuc tnh l phc tp, nhng n c c coi l mt cch tip cn km ti u trong cc kha cnh sau y:


11/40

u tin, kt hp c thc hin trn cc thuc tnh chit xut, khng phi trn ring chth. Bi v ni dung ca cc thuc tnh chit xut thay i,C kh nng tr v chng nhsai t pha Client nu vic chit xut cc thuc tnh c hi b gi mo. n c khuynmnh m cho Client xc nhn li chng th m bo an ton mc cao. V phaServer, bng cc cch khc nhau,Qun tr server phi m bo chc chn tnh ton vn cchng th v thuc tnh chit xut tng ng gim thiu cc l hng bo mt.

Th 2 , khi c nhiu hn mt chng th trong mc nhp ca th mc. n khng c kh xc nh v tr li chng th vi cc thnh phn ph hp ( V d v s dng li kha)tnghin cu cc thuc tnh khc nhau t cc thuc tnh tr v Vic kim sot gi tr ph khng gii quyt vn ny, bi v mt thuc tnh LDAP c thit lp gi tr, chui gV vy, n l khng th trnh khi chuyn i c cu DIT trong thit k mt giy chnhn DIT trnh s cn thit cho mt bc tm kim thm khch hng

. Th ba, khai thc thuc tnh khng to iu kin thun li ph hp i vi vic xc nhgi tr tng hp trong X.500. N khng phi l c th h tr mt kt hp linh hot nh tX.509 certificateMatch m khng lm cho my ch th mc LDAP nhn bit ASN.1

2.3.3 Certificate Parsing Server: My ch phn tch chng th

An automatic attribute extraction mechanism was recently proposed. The Certificate ParsingServer (XPS) designed by the University of Salford [3] extends the OpenLDAP directory servorder to automatically extract and store the certificate components. Although it can significantrelieve the PKI administrators burden, it does not improve the attribute extraction mechanismto suffer from the three disadvantages of described above.Mt c ch t ng chit xut thuc tnh gn y c xut. My ch phn tch chngth(XPS) c thit k bi trng i hc Salford m rng cc my ch th mc OpenLDAPt ng gii nn v lu tr cc thnh phn chng th . Mc d n c th lm gim ng k g

nng qun tr PKI, n khng ci thin c ba nhc im c ch khai thc thuc tnh trong m trn.

2.3.4 Component Matching

Component matching is recently published in RFC 3687 [18] in an effort to provide a completsolution to the LDAP - PKI interoper ability problem. All attribute syntaxes of X.500 and LDare originally described by ASN.1 type specifications [15, 10]. However, LDAP uses LDAPspecific encodings which does not generally preserves the structural information in the origina

ASN.1 type, insteadof relying on an ASN.1 encodings. The component matching defines a genway of enabling matching user selected components of an attribute value by introducing a newnotion of component assertion, component filter, and matching rules for components. Withcomponent matching, it becomes possible to perform matching of an assertion value against aspecific component of a composite attribute value. For example, infrastructure is provided to

perform matching against an arbitrary component of an X.509 certificate, such as serialNumbissuer, subject, and keyUsage. Technical details of the component matching will be explainedthe following sections. Compared to the attribute extraction approach, component matching hthe following advantages:1. It does not extract and store certificate components separate from the certificates themselveTherefore, it does not increase storage requirements and does not open a potential to thecompromised integrity between a certificate and its extracted attributes.


12/40

2. Matching is performed not on the extracted attributes contents but directly on the certificatcontent. It can return only the matched certificate out of multiple certificates in a users entry iis used in conjunction with the matched values control [4].3. It becomes convenient to provide a complex matching flexibly because matching betweenattribute and assertion values is performed at the ASN.1 layer.

Thnh phn ph hp c cng b gn y trong RFC 3687 trong mt n lc cung cp mgii php hon chnh v vn kh nng tng tc LDAP - PKI . tt c cc c php thuc tnhtrong X.500 v LDAP ban u c miu t c th trong ASN.1. LDAP s dng cc LDAP mha c th m ni chung khng lu gi thng tin cu trc kiu ASN.1 ban u, thay v da vha trong ASN.1. Thnh phn ph hp nh ngha mt cch chung chung cho php ngi s dla chn thnh ph hp vi ca mt gi tr thuc tnh bng cch a ra mt khi nim mi xnhn cc thnh phn , b lc thnh phn v cc quy tc ph hp cho cc thnh phn.Vi thnh

phn ph hp, n s tr thnh c th thc hin cho ph hp ca gi tr c xc nhn i vi gi tr thuc tnh ca thnh phn c th . V d, c s h tng c cung cp trin khai ph

i vi mt thnh phn ty ca chng ch X.509, nh serialNumber, t chc pht hnh, chv keyUsage. chi tit cng ngh thnh phn ca cc ph hp s c gii thch trong cc phny. So vi cc phng php tip cn khai thc thuc tnh, thnh phn ph hp c nhng u sau:1.N khng gii nn v lu tr cc thnh phn ring bit ca chng th . Do vy, n khng ltng yu cu lu tr v khng m ra mt tim n b xm nhp n tnh ton vn gia mt chth v cc thuc tnh c chit xut ca n.2.Kt hp c thc hin khng phi vo ni dung ca cc thuc tnh chit xut m trc tip vni dung ca chng th s.N c th ch tr v chng th ph hp trong s nhiu chng th tr

mc nhp ca ngi s dng nu n c s dng kt hp vi kim sot cc gi tr ph hp3. N tr nn thun tin cung cp linh hot kt hp phc tp bi kt hp gia thuc tnh vtr khng nh c thc hin lp ASN.1.

3 Component Matching for PKI :Thnh phn ph hp trong PKI

3.1 Component Matching and Its Usage:Thnh phn ph hp v s dng n

The attribute syntaxes of X.500 are defined in ASN.1 types. The type is structurally constructefrom basic types to composite types just like C struct definition. Every field of an ASN.1 typecomponent. Based on ASN.1 types, component matching [18] defines how to refer to a compowithin an attribute value and how to match the referred component against an assertion value.Matching rules are defined for the ASN.1 basic and composite types. It also defines a newassertion and filter tailored for a component, or each field of the ASN.1 type. These definition

based on ASN.1 so that they can be applied to any complex syntax, as long as it is specified inASN.1.

The search filter for component matching is a matching rule assertion whose matching rule iscomponentFilterMatch and whose assertion value is a component filter. The search filter forcomponent matching consists of three parts.


13/40

Matching Rule: specifies which matching rule will be used to perform matching on thevalues. Value: An assertion value in GSER.Cc c php thuc tnh ca X.500 c nh ngha trong kiu ASN.1. cc kiu ny c cu trcc dng t cc kiu phc hp c bn ging nh nh ngha cu trc trong C. Tt c cc trca ASN.1 l mt thnh phn.Da trn kiu ASN.1, thnh phn ph hp quy nh lm th notham chiu ti mt thnh phn bn trong mt gi tr thuc tnh v lm th no tham chiu t

phn ph hp i vi mt gi tr khng nh. Quy tc ph hp c nh ngha cho ASN.1 cv cc kiu kt hp. N cng nh ngha mt s khng nh mi v b lc ph hp cho mt th

phn, hoc mi field ca kiu ASN.1. Nhng nh ngha ny c da trn ASN.1 chng cth c p dng cho bt k c php phc tp, min l n c quy nh trong ASN.1.B lc tm kim cho cc thnh phn ph hp l mt s xc nhn cc quy tc ph hp m cc qtc ph hp y l componentFilterMatch cc gi tr xc nhn l mt b lc tm kim. B ltm kim cho thnh phn ph hp gm 3 phn:

Thnh phn tham kho: ch nh thnh phn no ca gi tr thuc tnh s thch ng vi gtr khng nh.

Quy tc ph hp: ch nh quy tc thch hp no s c s dng thc hin ph hp cc gi tr

Gi tr: mt gi tr xc nhn trong GSER

3.2 Certificate Access

Component matching, as introduced in Section 2.3.4, enables matching of an assertion valueagainst a specific component of a certificate such as serialNumber, issuer, subject, and keyUsaIf a client receives a reference to a certificate consisting of the name of the issuing CA and its

serial number, the client has to search for the certificate having matching issuer and serialNumcomponents in a certificate repository. Alternatively, a client may want to retrieve communicpartys certificates, not all of them, but only the ones for the non-repudiation purpose, by matcits distinguished name and key usage against the subject and keyUsage components of thecertificate. For instance, the client can make an LDAP search request having the search filterillustrated in Figure 2 (c) to search for the certificates of cn=John Doe,o=IBM,c=US that arearranged to be used for non-repudiation. The example component filter of Figure 2 (c) containtwo component assertions, one for subject and the other for keyUsage. The component referento these components begin with toBeSigned which is a sequence of certificate components to

digitally signed for immutability. toBeSigned.serialNumber refers to the serialNumber compoof a certificate while toBeSigned.extension.*.extnValue.(2.5.29.15) refers to any extension ofkeyUsage type. In the latter example, (2.5.29.15) is the object identifier (OID) of the keyUsagextension. It is contained in OCTET STRING of the extnValue of any components of extensiocertificate component. In other words, the reference means identifying all keyUsage extensioncomponents.Thnh phn ph hp, nh gii thiu trong mc 2.3.4, cho php kt hp ca mt gi tr khnnh i vi mt thnh phn c th ca mt chng ch nh serialNumber, t chc pht hnh, cth, v keyUsage. Nu mt khch hng nhn c mt tham chiu n mt giy chng nhn bgm tn ca CA nh pht hnh v s serial ca n, khch hng c tm kim cc chng ch ccng ty pht hnh ph hp v cc thnh phn serialNumber trong mt kho lu tr chng ch.

Ngoi ra, mt khch hng c th mun ly giao tip bn giy chng th ,khng phi tt c nh


14/40

LDAP c b lc tm kim c minh ha trong hnh 2 (c) tm kim giy chng nhn ca cnJohn Doe, o = IBM, c = US c sp xp c s dng cho mc ch chng chi b . v dthnh phn phn b lc ca hnh 2 (c) c cha hai thnh phn, khng nh mt cho ch th v keyUsage khc.Cc cc thnh phn tham chiu n cc thnh phn ny bt u vi toBeSigned m l mt chuca cc thnh phn chng th c k s khng thay i. toBeSigned.serialNumber cpcc thnh phn cachng thtrong khi toBeSigned.extension. extnValue (2.5.29.15) dng ch bt k phn m rng ca cloi keyUsage. Trong v d trn (2.5.29.15) l nh danh i tng (OID) ca phn m rngkeyUsage. N c cha trong STRING octet ca cc extnValue ca bt k thnh phn ca cch . Ni cch khc cc phng thc tham chiu nh danh tt c kha cc thnh phn m rnkeyUsage

The component matching rule specifies which matching rules will be used to perform matchincertificates component against an assertion value. Either existing matching rules or newly defimatching rules can be used as the component matching rules. Matching rules for composite ty

can be provided by combining those of their subordinate types. allComponentsMatch implemmatching at the ASN.1 layer whereas derived matching rules can be defined to override it withspecific syntaxesCc quy tc c th ca cc thnh phn kt hp ph hp vi cc qui tc s c s dng thhin khp mt thnh phn ca giy chng nhn i vi mt gi tr khng nh. Hoc l ph hvi qui tc hin ti hoc nh ngha cc quy tc c th c s dng nh cc quy tc thnh phkt hp. Quy tc ph hp cho cc loi tng hp c th c cung cp bng cch kt hp nhnloi cp di ca chng. allComponentsMatch trin khai ph hp lp ASN.1 trong khi cc qtc ph hp c dn xut c th c xc nh ghi ln n vi c php c th

RFC 3687 [18] defines which matching rules can be applied to each of the ASN.1 types. In theexample component filter in Figure 2 (c), distinguishedNameMatch is used for subject andStringMatch is used for keyUsage. The component assertion value is a GSER-encoded valueasserted against the component selected

by the component reference. In Figure 2 (c), the value cn=John Doe,o=IBM,c=US is the GSEencoded ASN.1 UTF8 STRING and the value 010000000B is the GSER encoded ASN.1 BISTRING value.

RFC 3687 nh ngha cc quy tc kt hp c th c p dng cho mi loi ASN.1. Trong v

cc b lc thnh phn trong hnh 2 (c), distinguishedNameMatch c s dng cho i tngStringMatch bit c s dng cho keyUsage.Cc thnh phn gi tr khng nh l mt gi trGSER m ha li cc thnh phn c la chn bi cc tham chiu thnh phn . Trong hnh 2gi tr cn = John Doe, o = IBM, c = US c m ha GSER ASN.1 STRING UTF8 v gi tr'010000000 'B c m ho l GSER ASN.1 gi tr STRING BIT.

The client sends a search request containing the component filter to a component matchingenabled LDAP directory server. In response, the client will be returned with those entries havithe matching certificate if there is any. After checking the authenticity and integrity of the retucertificate, the client can extract the public key out of the certificate for further use.Khch hng gi mt yu cu tm kim c cha cc b lc thnh phn n mt thnh phn phkch hot my ch th mc LDAP. Ti phn hi t server, khch hng s c tr li vi nhn


15/40

v tnh ton vn ca chng th tr v, khch hng c th trch xut cc kha cng khai trongchng th nhn tip tc s dng.


16/40

Certificate Revocation List (CRL) AccessAlthough certificates were valid at the time when they were issued, CA mustrevoke certificates occasionally because the key pair for a certificate can becompromised or the binding between an identity and a certificate becomeinvalid. As a result, a certificate should be validated when it is used.Otherwise, the client might incur not only incomplete, but also insecuretransactions. The CRL mechanism [11] provides a means of performingvalidation of certificates against periodically published list of revokedcertificates, or Certificate Revocation List (CRL). A CRL is periodicallygenerated by the CA and is made available through certificate repositoriessuch as LDAP directories. Although the CRL mechanism has been carefullyrevised to reduce the CRL download traffic which can degrade thescalability of PKI significantly, it still requires the end entities to store CRLsin its local storage in order to facilitate efficient and off-line operation. On

the other hand, on-line certificate validation protocols are also proposed inorder to cope with the on-line end entities which need more freshinformation on certificate validity. Because the on-line end entities need notstore the certificate status information in its storage, the on-line protocolsalso eliminate the requirement for the hefty local certificate storage. OnlineCertificate Status Protocol (OCSP) [21] and Simple Certificate ValidationProtocol (SCVP) [9] are two examples of the on-line certificate validation

protocols.Mc d cc chng ch l hp l ti thi im khi chng c ban hnh,CA i khi phi thu hi Chng th v cc cp kha cho mt chng ch c th

b tn hi hoc s gn kt gia ch th v chng th tr nn khng hp l.Kt qu l, mt chng th cn c xc nhn khi n c s dng. Nukhng th , khch hng khng ch s phi chu hon ton , m cn c giaodch khng an ton. C ch CRL cung cp mt phng thc thc hinxc nhn li chng th theo nh k ,cng b danh sch thu hi chng ch,hoc Certificate Revocation List (CRL). CRL c nh k c to ra bicc CA v c thc hin thng qua cc kho lu tr chng ch chng hnnh th mc LDAP. Mc d cc c ch CRL c sa i mt cch cnthn gim lu lng truy cp ti v CRL c th lm suy gim kh nng

m rng ng k ca PKI , n vn yu cu cc thc th cui cng lu trCRLs trong lu tr cc b to iu kin thun li cho hot ng hiu quv off-line. Mt khc, cc giao thc xc nhn trn chng th cng c xut i ph vi cc thc th cui trc tuyn m cn phi bit thm thngtin mi v tnh hp l chng ch. Bi v trn thc th cui cng cn lu trcc thng tin trng thi chng ch trong lu tr ca n, cc giao thc trctuyn cng loi b yu cu cho vic lu tr chng ch cc b. Online


17/40

Certificate Status Protocol (OCSP) v Simple Certificate ValidationProtocol (SCVP) l hai v d ca giao thc xc nhn trn chng ch.We conceive that component matching enabled LDAP can also be used asan on-line certificate validation protocol. CRL is a sequence of pairs of arevoked certificates serial number and revoked time [11]. In order to checkstatus of the certificate, the client needs to make a component assertionagainst the serial number of the certificate under scrutiny. Then, the LDAPserver will perform component matching on the CRL against the assertion tofind the asserted serial number in the CRL. This is possible with componentmatching, since the LDAP server understands the structure of the CRL andis able to compare specific components of the CRL against the componentassertion. In the attribute extraction approach, however, the serial numbersof all the elements of the revoked certificate list must be extracted asseparate attributes which need to be stored in the individual subordinate

entries. This not only increases the amount of storage and increases thecomplexity of managing directory significantly, but also makes the servervulnerable to malicious attacks as explained in Section 2.3.4.Chng ta nhn thy rng kch hot thnh phn ph hp vi LDAP cng cth c s dng nh l mt giao thc xc nhn chng ch trc tuyn. CRLl mt chui cc cp ca thi gian thu hi v s serial chng ch . kimtra tnh trng ca chng th, khch hng cn phi xc nhn li thnh phn sserial ca chng th di s gim st. Sau , cc my ch LDAP s thchin xc nhn li thnh phn ph hp trn CRL tm s serial trong CRL.iu ny l c th vi thnh phn ph hp, k t khi my ch LDAP hiuc cu trc ca CRL v c th so snh cc thnh phn c th ca CRL davo s xc nhn cc thnh phn . Trong cch tip cn khai thc thuc tnh,Tuy vy , s serial ca tt c cc thnh phn ca danh sch thu hi giychng nhn phi c chit xut nh l thuc tnh ring bit cn c lutr trong cc mc thuc c nhn. iu ny khng ch lm tng s lng lutr v lm tng tnh phc tp ca qun l th mc ng k, nhng cng lmcho my ch d b nh hng vi cc tn cng nguy him nh gii thchti mc 2.3.4.

With component matching, the whole CRL does not necessarily have to bedownloaded to the client and scanned by the client so as to save the network

bandwidth and the clients computing power significantly. Especially for theclients which have limited computing power and low bandwidth such asmobile devices, component matching will be very efficient solution for theclient to access PKI. Furthermore, an LDAP server already has been widelyused for distributing CRLs and certificates. Hence, if the server can perform


18/40

on-line validity checking over the CRL as well, it will be very practical andefficient alternative to OCSP which needs additional software, or an OCSPresponderVi cc thnh phn ph hp, tt c CRL khng nht thit phi c ti xung cho khchhng v scan bi khch hng tit kim bng thng mng v sc mnh tnh ton mt

cch ng k. c bit i cc khch hng c cng sut my tnh hn ch v bng thngthp nh thit b di ng, cc thnh phn ph hp l gii php rt hiu qu cho khch hng truy cp PKI. C nhiu hn mt my ch LDAP c s dng rng ri phn phiCRLs v giy chng nhn.Do , nu my ch c th thc hin kim tra tnh hp l trctuyn trn CRL l tt, n s l rt thit thc v hiu qu thay th cho OCSP c nhu cuthm phn mm, hoc phn hi OCSP

In [6], we also propose to structure the internal representation of CRL as anauthenticated data structure such as the Certificate Revocation Tree (CRT)

[16] and the authenticated 2-3 tree [23]. Together with the componentmatching, it makes certificate validation result from an LDAP serverunforgeable while not requiring to have the LDAP server as a trusted entitynor to sign every LDAP response on the fly as in OCSP.chng ta cng xut vi cu trc biu din bn trong ca CRL nh l mtcu trc d liu chng thc nh Certificate Revocation Tree(CRT) .Cngvi thnh phn ph hp , n lm cho kt qu xc thc chng th t mt myLDAP khng th on trc trong khi khng yu cu phi c my chLDAP nh mt thc th tin cy cng khng phi k vo tng tr li LDAPmt cch nhanh chng nh trong OCSP.

4 GSER (Generic String Encoding Rules)A native LDAP encoding does not represent structure of an ASN.1 type.Instead, it is either in octet string or in binary. With the LDAP encoding, as aresult, it is difficult to contain the structural information of ASN.1 type in itsrepresentation. In order to solve this problem, S. Legg [17] recently

proposed GSER (Generic String Encoding Rules). Component matchinguses GSER as its basic encoding for the component assertion value. GSERgenerates a human readable UTF-8 character string encoding of a given

ASN.1 specification with predetermined set of characters to keep thestructure such as {, }, and ,. It defines UTF8 string encodings at thelowest level of the ASN.1 built-in types such as INTEGER, BOOLEAN, andSTRING types and then it builds up more complex ASN.1 types such asSEQUENCE and SET from the lowest level by using the characters. Thus,the structural information of an ASN.1 specification is maintained inencodings so that it can be recovered in the decoding process easily. By


19/40

using GSER to store attribute values instead of the native LDAP encoding,an LDAP server is capable of identifying the structure of ASN.1specification of the attribute. Furthermore, the component filter itself is alsoencoded in GSER Hence, GSER is an essential mechanism to ASN.1awareness and component matching.

Mt LDAP m ha ring khng th hin cu trc ca mt loi ASN.1. Thayvo , n l mt trong hai trong chui octet hoc nh phn. Vi m haLDAP, kt qu l, n l rt kh cha thng tin cu trc ca loi ASN.1nh trong trnh by ca n. gii quyt vn ny, S. Legg [17] xutGSER (Generic String Encoding Rules). Thnh phn ph hp s dngGSER nh m ha c bn ca n cho s xc nhn gi tr cc thnh phn.GSER to ra gip chng ta c th c c m ha chui k t UTF-8 camt cho c t ASN.1 vi nh sn ca cc k t gi cho cc cu trc nh

'{', '}', v ','. N nh ngha cc m ha chui UTF-8 mc thp nht caASN.1 c xy dng trong cc kiu nh INTEGER, BOOLEAN, v ccloi STRING v sau n c xy dng ln phc tp hn kiu ASN.1chng hn nh SEQUENCE v SET t mc thp nht bng cch s dng kt. Nh vy, thng tin cu trc ca mt c t ASN.1 c duy tr trong mha n c th c khi phc trong qu trnh gii m mt cch d dng.Bng cch s dng GSER lu tr cc gi tr thuc tnh thay v m haring LDAP, mt my ch LDAP l c kh nng xc nh cc cu trc cac t thuc tnh ca ASN.1. Hn na, cc b lc thnh phn ca n cngc m ha trong GSER Do , GSER l mt c ch cn thit thnh

phn ph hp nhn thc c ASN.1Figure 4 shows the ASN.1 type specification of a toBeSigned and its GSERencodings. The certificate is SEQUENCE so that there are curly braces at the

beginning and at the end of its GSER encodings. It has version,serialNumber, etc. as its components inside of SEQUENCE. Within the

braces, there is version and 2, or its value, followed by comma whichseparates the subsequent field encoding. GSER defines each basic typesencoding and then combines them structurally to a more complex one byusing {, , and }. On the other hand, a native LDAP encoding does not

have any systematic rule to construct the structure information of attributevalue in it.


20/40

Hnh 4 cho thy c t kiu ASN.1 ca mt toBeSigned v m ha GSER ca n. chngch l SEQUENCE c du ngoc mc u v cui ca m ha GSER ca n. N cphin bn, serialNumber, vv... nh l cc thnh phn ca n bn trong SEQUENCE. Trongdu ngoc ({}), c phin bn 2, hoc gi tr ca n, theo sau bi du phy ngn cch mha trng tip theo. GSER nh ngha kiu m ha c bn ca tng loi v sau kt hpchng thnh cu trc phc tp hn bng cch s dng "{", "," v "}". Mt khc, mt LDAPm ha ring khng c bt k quy tc h thng no xy dng thng tin cu trc ca gitr thuc tnh trong n.

5 Component Matching Implementation inOpenLDAPThe overall conceptual architecture of the component matching in theOpenLDAP slapd directory server is illustrated in Figure 5. Given theASN.1 specification of the X.509 certificate as an input, the extendedeSNACC ASN.1 compiler generates the slapd internal data representation ofthe X.509 certificate and their encoding / decoding routines. We extendedthe eSNACC ASN.1 compiler [7] to support GSER in addition to theoriginally supported BER and DER [7]. It also generates component equality


21/40

matching rules, component extract functions, and component indexerfunctions which will be discussed later in this section in detail. In order tofacilitate the integration of the newly defined syntaxes without the need ofrebuilding the slapd executable, the generated data structures and routinesare built into a module which can be dynamically loaded into slapd. Theoverall flows of LDAP component search is explained as follows;Khi nim kin trc tng th ca cc thnh phn ph hp trong cc my ch th mcOpenLDAP Server c minh ha trong hnh 5

. a ra c t ASN.1 ca chng ch X.509 nh l mt u vo, trnh bin dch m rngeSNACC ASN.1 sinh ra cc biu din slapd d liu bn trong ca chng ch X.509 v mha / gii m thng thng. chng ta m rng trnh bin dch eSNACC ASN.1 h trGSER ngoi ra h tr BER u tin sau l DER . N cng to ra cc quy tc ccthnh phn ph hp, cc chc nng chit xut t thnh phn, thnh phn v cc chc nngch mc s c tho lun chi tit sau phn ny. to iu kin thun li cho vic tchhp ca cc quy nh cc c php mi m khng cn phi xy dng li thc thi slapd, cutrc d liu c to ra v chng trnh c xy dng thnh mt m-un c th c tng np vo slapd. Cc dng chy chung ca thnh phn tm kim LDAP c gii thch

nh sau;1. On the client side, a search for components of X.509 certificate is

initiated by the inclusion of the ComponentFilter in the filter of thesearch request. A ComponentFilter consists of ComponentAssertionseach of which is in turn comprised of component, rule, and value.

V pha Client, tm kim cho cc thnh phn ca chng ch X.509 cbt u bi s bao gm ca ComponentFilter trong cc b lc ca cc


22/40

yu cu tm kim. ComponentFilter bao gm ca ComponentAssertionsmi trong s l ln lt bao gm cc thnh phn, lut v gi tr.2. On the server side, whenever slapd detects that the search request

contains ComponentFilter, it parses the incoming component filter toobtain assertion values and component references. The assertionvalues are also converted to the ASN.1 internal representation by theGSER decoder

V pha my ch, bt c khi no slapd pht hin ra cc yu cu tm kim chaComponentFilter, n tch cc thnh phn gi n cc b lc xc nhn cc gi tr v ccthnh phn tham chiu. cc gi tr va c xc nhn cng c chuyn i biu dinbn trong ASN.1 bi b gii m GSER3. Retrieve the entry cache to see if the target certificates decoded

component tree is cached. If so, skip the following steps upto the step6.

4. Tm kim trong b nh cache xem nu cy thnh phn c gii m chng ch ch

ang lu tr.Nu nh vy, b qua cc bc sau bc 65. If it is not cached, by using an appropriate ASN.1 decoder, slapd

decodes the certificate attribute into the component tree, the ASN.1internal representation, when loading the candidate entries containingcertificate for matching. Because a certificate is DER encoded, DERdecoder is used to construct a certificates component tree.

Nu n khng c cached, bng cch s dng mt b gii m ASN.1 thch hp slapdgii cc thuc tnh chng ch vo trong cy thnh phn biu din ASN.1 bn trong khiti cc mc ng c vin c chng ch ph hp. Bi v mt chng ch c BER mha, b gii m DER c s dng xy dng mt cy thnh phn ca chng ch.

6. The component reference is fed into the component extractor to obtainthe component subtree which is referenced by component referenceout of the attribute component tree.

tham chiu cc thnh phn c np vo thnh phn gii nn c c cc thnhphn subtree c tham chiu bng cch tham chiu ti cc thnh phn ca cy thnhphn thuc tnh .7. The assertion component and the extracted attribute component are

then matched together by the matching rule corresponding to thecomponent which is generated also by the extended eSNACCcompiler. Matching is performed at the abstract level using the

internal ASN.1 data representation.Thnh phn xc nhn v thnh phn thuc tnh chit xut sau s kt hp vi nhau bngcc quy tc ph hp tng ng vi cc thnh phn cng c to ra bi trnh bin dcheSNACC m rng. Vic kt hp c thc hin mc tru tng bng cch s dng mt d liu bn trong ASN.1.


23/40

The rest of the section provide detailed description of the componentmatching in two steps. After first describing how to make the OpenLDAPdirectory server ASN.1 aware in detail, component filter processing,aliasing, component indexing, and component caching will be described.Phn cn li ca phn ny cung cp m t chi ca cc thnh phn ph hp trong hai bc.Sau m t u tin lm th no to my ch th mc OpenLDAP nhn bit ASN.1 mtcch chi tit, thnh phn b lc x l, b danh, thnh phn ch mc, thnh phn b nh ms c m t.

5.1 ASN.1 Awareness

5.1.1 eSNACC Compiler

Figure 6 shows the internal data representation of the toBeSigned ASN.1type along with the representations of some of its key components. The data

structures for this ASN.1 data representation are automatically generated bythe eSNACC compiler from the given ASN.1 specification of toBeSigned.The generated data structure for the toBeSigned has data fieldscorresponding to components of the toBeSigned ASN.1 type. Once theinternal data structure for toBeSigned is instantiated, it can be converted toDER by DEnctoBeSigned() and back to the internal representation byDDectoBeSigned().


24/40

Hnh 6 cho thy s m t bn trong ca toBeSigned kiuASN.1 cng vi s m t mt sthnh phn quan trng ca n . Cc cu trc d liu m t cho ASN.1 c t ng to rabi trnh bin dch eSNACC da vo c t ASN.1 ca toBeSigned.Cu trc d liu to ra

cho toBeSigned c cc trng d liu tng ng vi cc thnh phn ca toBeSigned kiuASN.1. Mt khi cc cu trc d liu bn trong toBeSigned c khi to, n c thc chuyn n DER DEnctoBeSigned () v m t bn trong DDectoBeSigned ().Component matching can be performed for any composite attributes whichare encoded as one of the ASN.1 encoding rules. In addition to the DERused for a certificate, we have implemented a GSER backend in the extendedeSNACC compiler. GSER can be used as an LDAP-specific encodings for


25/40

newly defined attribute types. With GSER, string-based LDAP-specificencodings can maintain the structure of their corresponding ASN.1 types.The assertion values in the component filter are also represented in GSERand the extended eSNACC compiler is used to decode them into theirinternal representationsthnh phn ph hp c th c thc hin cho bt k thuc tnh tng hp no c m hanh l mt trong cc quy tc m ha ASN.1. Ngoi ra s dng DER cho mt chng ch,chng ta trin khai thc hin mt ph tr GSER trong trnh bin dch eSNACC mrng. GSER c th c s dng nh l mt b m ha LDAP-c th cho cc loi thuctnh mi c xc nh. Vi GSER, m ha c th da trn chui LDAP c th duy tr cutrc ca kiu ASN.1 tng ng ca chng. Cc gi tr c s xc nhn nh trong cc blc thnh phn cng c m t trong GSER v trnh bin dch m rng eSNACC c sdng gii m chng thnh cc th hin bn trong ca chng

5.1.2 Internal Representation of ASN.1 Type

A new data structure of slapd is needed to represent an attribute value as itscomponents because the original data structure for attribute types does notcontain the structural information of an ASN.1 type in its representation.Every field of an ASN.1 type is a component which is addressable by acomponent reference. In our implementation, the component data structureconsists of two parts: one to store the value of the component; the other tostore a component descriptor which contains information on how to encode,decode, and match the values.Mt cu trc d liu mi ca slapd l cn thit m t mt gi tr thuc tnh nh ccthnh phn ca n bi v cu trc d liu ban u i vi cc loi thuc tnh khng chathng tin cu trc m t ca mt loi ASN.1. tt c cc trng ca ASN.1 l mt thnhphn trong c ch nh bi mt thnh phn tham chiu . Trong trin khai ca chngta, thnh phn cu trc d liu bao gm hai phn: mt lu tr cc gi tr ca cc thnhphn mt lu tr mt m t thnh phn trong c cha thng tin v lm th no m, gii m, v kt hp cc gi tr .

The data structure of a component appears as a tree which keeps thestructural information of the original ASN.1 specification using nodes andarcs. Each component node of the tree not only has data values but also

represents the structural information of the given ASN.1 specification byhaving links to subordinate nodes. In the tree, any node can be referenced bya component reference in order to perform matching on the correspondingcomponent. Hence, we need a function to traverse the tree and locate thereferenced node. The ASN.1 compiler also generates component extractorroutines for this purpose.


26/40

Cu trc d liu ca mt thnh phn xut hin nh mt cy m gi thng tin cu trc ct ban u ca ASN.1 bng cch s dng cc nt v cc cung . vi mi nt thnh phn cacy khng ch c cc gi tr d liu m cn biu din cc thng tin cu trc ca c tASN.1 c lin kt n cc nt cp di. Trong cy, bt k nt no c th c tham chiubi mt tham chiu thnh phn nhm thc hin ph hp trn cc thnh phn tng ng. Do

, chng ta cn mt chc nng i qua cy v xc nh v tr cc nt tham chiu. Trnhbin dch ASN.1 cng to ra cc trnh gii nn cho cc thnh phn phc v mc ch ny.

Figure 6 illustrates the component data structure for Certificate.toBeSigned.For the convenience of illustration, only serialNumber, signature, issuer, andsubjectPublicKeyInfo are shown with their component subtrees among tencomponents of Certificate.toBeSigned. Lets look at subjectPublicKeyInfo inmore detail. Its component data structure, ComponentSubjectPublicKeyInfo,contains a pointer to its component descriptor and its own subordinatecomponents, algorithm and subjectPublicKey. Algorithm is represented by

ComponentAlgorithmIdentifier and subjectPublicKey is of the ASN.1 BITSTRING type which is represented by ComponentBits. Leaf nodes of thecomponent tree, such as ComponentBits and ComponentInt, contain thevalues of the ASN.1 basic types.Hnh 6 minh ha cc cu trc d liu thnh phn cho Certificate.toBeSigned. i vi cctin ch trong hnh minh ha, ch serialNumber, ch k, t chc pht hnh, vsubjectPublicKeyInfo c hin th vi subtrees thnh phn ca chng trong s mithnh phn ca Certificate.toBeSigned. Chng ta hy nhn vo subjectPublicKeyInfo chitit hn. Thnh phn cu trc d liu ca n: ComponentSubjectPublicKeyInfo, cha mtcon tr m t thnh phn ca n v cc thnh phn cp di, thut ton v

subjectPublicKey. Thut ton c i din bi ComponentAlgorithmIdentifier vsubjectPublicKey l loi STRING ASN.1 BIT c i din bi ComponentBits. Cc ntl ca cy thnh phn ca n, chng hn nh ComponentBits v ComponentInt, cha ccgi tr kiu c s ca ASN.1 .

5.1.3 Syntax and Matching RulesAn attribute is described by an attribute type in LDAP. An attribute typecontains two key fields which help to define the attribute as well as the rulesthat attribute must follow. The first field is syntax which defines the dataformat used by the attribute type. The second field is matching rule which is

used by an LDAP server to compare an attribute value with an assertionvalue supplied by LDAP client search or compare operations. Attributesmust include the matching rules in their definition. At least, equalitymatching rule should be supported for each attribute type. From theviewpoint of an LDAP server, an ASN.1 specification defining a newattribute type requires a new syntax and its matching rule to be defined. Tofully automate the component matching in which the composite attribute


27/40

types are defined in ASN.1, we extended the eSNACC compiler to generatethe basic equality matching rule of a given ASN.1 type, orallComponentMatch matching rule specified in RFC 3687 [18].allComponentMatch matching rule evaluates to true only when thecorresponding components of the assertion and the attribute values are thesame. It can be implemented by performing matching from the topmostcomponent which is identified by the component reference recursively downto the subordinate components. The generated matching function of eachcomponent can be overridden by other matching functions through amatching rule refinement table. Therefore, it is possible that a syntaxdeveloper can replace the compiler-generated matching functions with theexisting matching functions of slapd which might be more desirable. Inorder to support this refining mechanism, slapd checks the refinement tablewhether it is overridden by looking up the table, whenever a matching

functions are executedMt thuc tnh c m t bi mt loi thuc tnh trong LDAP. Mt loithuc tnh bao hai trng quan trng m gip nh ngha cc thuc tnh cngnh cc quy tc m thuc phi tun theo. Trng u tin l c php trong xc nh nh dng d liu c s dng bi cc loi thuc tnh. Trngth hai l quy tc ph hp c s dng bi mt my ch LDAP so snhmt gi thuc tnh vi mt gi tr xc nhn h tr bi LDAP vi hot ngtm kim hoc so snh ca khch hng . Cc thuc tnh phi bao gm ccquy tc ph hp trong nh ngha ca chng. t nht, quy tc ph hp ngangnhau cn c h tr cho mi loi thuc tnh. t cc quan im ca mt mych LDAP, mt c t ASN.1 xc nh mt loi thuc tnh mi i hi mtc php mi v quy tc ph hp ca n c xc nh. t ng ho honton cc thnh phn ph hp trong cc kiu thuc tnh tng hp cnh ngha trong ASN.1, chng ta m rng cc trnh bin dch eSNACC to ra cc quy tc c bn ph hp ngang nhau ca mt loi ASN.1 , hocallComponentMatch quy tc ph hp theo quy nh trong RFC 3687 .allComponentMatch quy tc ph hp c nh gi l true ch khi cc thnh

phn tng ng ca gi tr xc nhn v cc gi tr thuc tnh l nh nhau. Nc th c trin khai bng cch thc hin ph hp t cc thnh phn trn

cng c xc nh bi thnh phn tham chiu quy xung cc thnh phncp di . Chc nng ph hp c to ra bi mi thnh phn c th cghi bi cc chc nng ph hp khc thng qua mt bng sng lc quy tc

ph hp . Do vy , n c th l mt nh pht trin c php c th thay thcc trnh bin dch to ra cc chc nng ph hp vi chc nng ph hp hinhnh ca slapd m c th l hn mong mun. h c ch lc ny, slapd


28/40

kim tra bng sng lc xem n c ghi bng cch nhn ln bng, bt ckhi no mt chc nng ph hp c thc hin5.2 Component Matching5.2.1Component Assertion and Filter

RFC 3687 [17] defines a new component filter as the means of referencing acomponent of a composite attribute and as the means of representing anassertion value for a composite attribute types. Component assertion is anassertion about presence or values of components within an ASN.1 value. Ithas a component reference to identify one component within an attributevalue. Component filter is an expression of component assertion, whichevaluates to either TRUE, FALSE, or Undefined while performingmatching. Figure 7 illustrate the example component filter. The componentreference or toBeSigned.serialNumber identifies one component in thecertificate attribute value. In the component reference, . means identifyingone of components subordinate to the preceding component. In thecomponent assertion, rule is followed by an integerMatch matching rule [15]which will be used to compare the following assertion value with thereferenced component of the attribute value. The routines required to supportthe component filter and the component assertion were hand-coded while theroutines for the component assertion values are automatically generatedfrom a given ASN.1 type.RFC 3687 nh ngha mt b thnh phn mi nh l phng tin tham chiu n mt

thnh phn ca mt thuc tnh tng v cc phng tin m t cho l mt gi tr xc nhncho mt loi thuc tnh tng hp. thnh phn xc nhn th xc nhn v s hin din hocgi ca cc thnh phn bn trong mt gi ASN.1. N c mt thnh phn tham chiu xcnh mt thnh phn trong l mt gi tr thuc tnh.thnh phn b lc l s th hin cathnh phn xc nhn thnh phn ,"." trong nh gi cc eitherTRUE,"." FALSE,"." hocKhng xc nh trong khi thc hin kt hp.


29/40

Hnh 7 minh ha cc b lc thnh phn v d. tham chiu hay thnh phntoBeSigned.serialNumber xc nh mt thnh phn trong chng ch gi tr thuc tnh.

Trong tham chiu thnh phn ,"." c ngha l xc nh mt trong cc cc thnh phn cpdi ti cc thnh phn trn y. Trong s xc nhn cc thnh phn quy tc c theosau bi mt quy tc ph hp integerMatch [15] m s c s dng so snh gi tr xcnhn sau y vi thnh phn tham chiu ca gi tr thuc tnh. Cc chng trnh con cnthit h tr cc b lc thnh phn v xc nhn thnh phn c m ha tay trong khicc chng trnh cho cc gi tr xc nhn ca thnh phn c to t ng a ra t mtloi ASN.1.

5.2.2 Attribute / Matching Rule Aliasing

To enable component matching, clients as well as servers need to support

GSER and new component matching rules. However, the client side changeswill be minimal if at all, because the component filter can be specified byusing the existing extensible matching rule mechanism of LDAPv3 and thecomponent assertion value is represented as the text centric GSER encodingrules. Especially, the clients that accept search filters as strings require nochanges to utilize component matching other than filling in the necessarycomponent filter as the search filter. However, for those clients who havesearch filters hard coded in them, we propose an attribute aliasingmechanism which maps a virtual attribute type to an attribute componentand a component matching rule and a matching rule aliasing mechanismwhich maps a virtual matching rule to a component assertion. kch hot tnh nng kt hp thnh phn, khch hng cng nh cc my ch cn phi htr GSER v quy tc ph hp vi thnh phn mi. Tuy nhin, s thay i pha khch hng mc ti thiu nu c th, bi v cc b lc thnh phn c th c xc nh bng cch sdng c ch m rng quy tc ph hp hin c ca LDAPv3 v xc nhn cc gi tr thnhphn c th hin nh cc quy tc m ha vn bn trung tm GSER. c bit, khchhng chp nhn cc b lc tm kim nh cc chui yu cu khng thay i s dng


30/40

thnh phn ph hp khc hn l in vo cc b lc thnh phn cn thit nh cc b lctm kim. Tuy nhin, i vi nhng khch hng c cc b lc tm kim m ha cngtrong chng, chng ta xut mt c ch thuc tnh b danh nh x mt loi thuc tnh oti mt thnh phn thuc tnh v quy tc thnh phn ph hp , c ch b danh cc quy tcph hp nh x mt quy tc ph hp hp o n mt thnh phn xc nhn

Attribute alias registers a set of virtual attributes to an LDAP server. Thevirtual attributes themselves find corresponding matching rules andcomponent references by looking up an attribute alias table. The exampleattribute alias table is shown in Table 1.X509certificateSerialNumberattribute is aliased to userCertificate.toBeSigned.serialNumber with theintegerMatch matching rule. Hence, the filter(x509certificateSerialNumber=12345) is considered equivalent to(userCertificate:ComponentFilter:=item:componentuserCertificate.toBeSigned.serialNumber, rule caseExactMatch, value12345). With the attribute aliasing, clients only have to form simpleassertions to utilize component matching. Matching rule alias works in asimilar way. An alias matching rule is mapped into the correspondingcomponent reference and matching rule.5.2.3 Component Indexing

The maintenance of proper indices is critical to the search performance in

the Component Matching as much as in the conventional attribute matching.In slapd, the attribute indexing is performed by generating a hash key valueof the attribute syntax, matching rule, and the attribute value and maintainthe list of IDs of those entries having the matching value in the set ofattribute values of the indexed attribute.Vic ng k mt tp hp thuc tnhb danh ca cc thuc tnh o n mt my chLDAP. Cc thuc tnh o t tm thy cc qui tc ph hp tng ng v thnh phn thnhphn tham chiu bng cch nhn ln mt bng cc thuc tnh b danh . Chng hn bngthuc tnh b danh c th hin trong Bng thuc tnh 1

.X509certificateSerialNumber c ly b danh n"userCertificate.toBeSigned.serialNumber" vi quy tc integerMatch ph hp. Do , ccb lc "(x509certificateSerialNumber = 12345)" c coi l tng ng vi"(userCertificate ComponentFilter: = mc: thnh phn


31/40

userCertificate.toBeSigned.serialNumber, quy tc caseExactMatch, gi tr 12345)". Vi ccthuc tnh aliasing, khch hng ch phi xc nh dng n gin s dng thnh phn phhp. Cc quy tc ph hp b danh hot ng trong mt cch tng t. Mt quy tc b danhph hp c nh x vo cc thnh phn tham chiu tng ng v quy tc ph hp.

The component indexing can be specified in the same way as the attributeindexing, except that the component reference is used to specify whichcomponent of a composite attribute to be indexed. If the referencedcomponent is a basic ASN.1 type, the indexing procedure will be the sameas the attribute indexing. The indices for the referenced component areaccessed through a hashed value of the corresponding syntax, matching rule,and value in the index file for the referenced component of the compositeattribute. In OpenLDAP, the indexing of the composite component iscentered on the GSER encoding of the component value. The hash key of acomponent value is generated from its GSER encodings together with itssyntax and matching rule. For the SET and SET OF constructed types, it isrequired to canonicalize the order of the elements in the GSER encodings

before generating the hashed key value. For component reference ofSET OF and SEQUENCE OF constructed types, its is needed to union theindices for each value element of SET OF and SEQUENCE OF.Thnh phn ch mc c th c quy nh trong cng mt cch nh l ch mc thuc tnh,ngoi tr vic c thnh phn tham chiu c s dng ch nh thnh phn ca mtthuc tnh tng hp c nh ch mc. Nu cc thnh phn tham chiu l mt loi ASN.1c bn, th tc lp ch mc s l tng t nh vic lp ch mc thuc tnh. Cc ch s chocc thnh phn tham chiu c truy cp thng qua mt gi tr bm ca cc c php tng

ng, quy tc ph hp, v gi tr trong tp tin ch mc cho cc thnh phn tham chiu cacc thuc tnh tng hp. Trong OpenLDAP, ch mc ca cc thnh phn tng hp c tptrung vo cc m ha GSER ca gi tr thnh phn. Key ca gi tr thnh phn hash cto ra t m ha GSER ca n cng vi c php v quy tc ph hp ca n. i vi loicu trc SET v SET OF, n c yu cu hp quy tc th t ca cc yu t trong ccbng m GSER trc khi to ra cc gi tr quan trng bm. Tham chiu tt c thnhphn ca cc loi cu trc ca SET OF v SEQUENCE, n l cn thit kt hp cc chs cho mi phn t gi tr ca SET OF v SEQUENCE OF.

5.2.4 Component CachingWhenever a certificate is matched against an incoming component filter, it is

repeatedly decoded into the internal representation fromDER. This requiresnon-negligible CPU cycles as presented in Table 2.Bt c khi no mt chng ch c so snh vi mt b lc thnh phn gi n, n lin tcc gii m thnh biu din ni b t DER. iu ny i hi cc chu trnh CPU ng knh trnh by trong Bng 2.


32/40

In order to eliminate the repeated decoding overhead, we decided to cachecertificates in their decoded form, i.e. in the component tree structureexplained in Section 5.1.2. In the OpenLDAP directory server, the entrycache is provided to store frequently requested entries to enable very lowlatency access [5]. We extended the current entry cache to store decodedcertificates along with other attributes of the entry. We devised variouscaching policies for the entry cache. In early implementations, we decided tocache a decoded certificate as a whole, along with its entry in the entrycache. The size of a certificate is 899Bytes and that of the correspondingcomponent tree is 3KBytes. Caching all the decoded component treeconsumes more than three times as much memory compared to the baseentry caching. To reduce the memory requirements, we devised an indexing

based caching policy. Since it is a common practice to index those attributesthat are likely to be asserted, caching only those indexed components is avery practical solution to reduce the memory requirement. In ourexperiment, the serial number component was cached which takes only148Bytes of memory.

loi cc chi ph gii m lp i lp li, chng ta quyt nh cache cc chng ch didng gii m ca n, tc l trong cu trc cy thnh phn c gii thch trong Phn 5.1.2.Trong my ch th mc OpenLDAP, mc cache c cung cp thng xuyn lu trcc mc c yu cu cho php truy cp vi tr rt thp, hin nay chng ta m rngmc cache lu cc chng ch c gii m cng vi thuc tnh khc ca cc mc nhp.chng ta a ra chnh sch cache khc nhau cho cc mc ca cache . Trong trin khaiu, chng ta quyt nh cache mt chng ch c gii m nh ton b, cng vi mcnhp ca n trong mc Cache. Kch thc ca mt chng ch l 899Bytes v cy thnhphn tng l 3KBytes. Caching tt c cc cy thnh phn c gii m tiu tn b nhhn ba ln so vi so vi mc b nh m c s. gim cc yu cu b nh , chng ta ngh ra mt chnh sch da vo nh ch s b nh m. . V n l mt thc t ph bin

ch lp ch s cho nhng thuc tnh c th c xc nhn, ch lp ch s cho nhng thnhphn l mt gii php rt thit thc gim bt yu cu b nh.Trong th nghim cachng ta, ch cn thnh phn s serial c lu trong b nh cache

6 Component Matching in WS-Security

SOAP (Simple Object Access Protocol) is a protocol for invoking methodson servers, services, components, and objects [1]. It is a way to create widely


33/40

distributed, complex computing environments that run over the Internetusing existing Internet infrastructure, enabling Web service developers to

build Web services by linking heterogeneous components over the Internet.For interpretability over heterogeneous platforms, it is built on top of XMLand HTTP which are universally supported in most services. WS-Security isrecently published as the standard for secure Web Services [24]. It providesa set of mechanisms to help Web Services exchange secure SOAP message.WS-Security provides a general purpose mechanism for signing andencrypting parts of a SOAP messages for authenticity and confidentiality. Italso provides a mechanism to associate security tokens with the SOAPmessages to be secured. The security token can be cryptographicallyendorsed by a security authority. It can be either embedded in the SOAPmessage or acquired externally. There are two types of PKI clients in WS-Security: onedirectly accesses PKI; the other indirectly accesses it by using

service proxies such as XML Key Management System (XKMS) [30] whichprovides clients with a simple-to-use interface to a PKI so as to hide thecomplexities of the underlying infrastructure.SOAP (Simple Object Access Protocol) l mt giao thc gi cc phng thc trn mych,cc dch v, cc thnh phn, cc i tng . l mt cch to phn phi rng ri,Mi trng tnh ton phc tp chy trn Internet bng cch s dng c s h tngInternet hin c, cho php pht trin dch v Web xy dng cc dch v Web bng cchlin kt cc thnh phn khng ng nht trn Internet. chy c trn nn tng khngng nht, n c xy dng trn XML v HTTP c ph bin trong hu ht cc dch vh tr. WS-Security c cng b gn y nh l tiu chun cho bo mt cc dch v Web. N cung cp mt tp hp cc c ch gip trao i thng ip an ton cc dch v WebSOAP. WS-Security cung cp mt c ch tng qut dng k v m ha cc b phn camt thng ip SOAP cho tnh xc thc v bo mt. N cng cung cp mt c ch gnkt cc th token vi cc thng ip SOAP c an ton. Cc th bi an ton c th cm ha chng thc bi mt c quan an ninh. N c th c nhng trong thng ipSOAP hoc mua li bn ngoi. C hai loi khch hng PKI trong WS-Security: trc tiptruy cp PKI cch khc gin tip truy cp bng cch s dng dch v y quyn nh hthng qun l XML Key (XKMS), trong cung cp cho khch hng vi mt giao dinn gin s dng-mt PKI che giu s phc tp ca c s h tng bn di .

In the X.509 token profile of WS-Security [25], it is defined that the

following three types of token references can be used:Trong h s c nhn th bi X.509 ca WS-Security [25], n c nh ngha ba loi sauy ca cc tham chiu th bi c th c s dng:

1. Reference to a Subject Key Identifier: value of certificatesX.509SubjectKeyIdentifier.


34/40

Tham chiu ti mt nh danh kha ca ch th: gi trX.509SubjectKeyIdentifier ca chng ch2. Reference to a Security Token: either an internal or an external URIreference.Tham chiu ti mt th bi: hoc l mt tham chiu bn trong hoc l bnngoi URR3. Reference to an Issuer and Serial Number: the certificate issuer and serialnumber.Tham chiu ti nh pht hnh v s Serial: t chc pht hnh v s Serialca chng ch

Because it is defined as extensible, any security token can also be used based

on schemas. It is shown in Figure 8 that the element of is used as the security token. defined in [31]contains various references such as X509IssuerSerial, X509SubjectName,X509SKI, and so on. With the ASN.1 awareness and the componentmatching support in the OpenLDAP directory server, these references can beused without the need of implementing syntax specific matching rules forvarious types of references. It is also possible in to useelements from external namespace for further flexibility.Bi v n c nh ngha l c th m rng, bt k th an ton no cng c th c sdng da trn lc . N c th hin trong hnh 8 rng cc phn t ca

c s dng nh l th token an ton. quy nh trong baogm cc cc tham chiu khc nhau nh X509IssuerSerial, X509SubjectName, X509SKI,v nh vy. Vi nhn thc v ASN.1 v cc thnh phn ph hp h tr trong cc my chth mc OpenLDAP, nhng ti liu tham kho c th c s dng m khng cn thchin cc c php c th ca cc qui tc ph hp vi nhiu loi tham chiu. N cng ctrong s dng cc phn t t min khng gian bn ngoi cho linh hot hnna.


35/40

Figure 8 shows one such example. Here, GenericCertificateReferenceelement from dsext namespace is used to provide a generic referencemechanism which implements CertificateMatch in the X.509recommendation [14]. The reference consists of a sequence of certificateattributes, serialNumber, issuer, subjectKeyIdentifier, authorityKeyIdentifier,certificateValid, privateKeyValid, subjectPublicKeyAlgID, keyUsage,subjectAltName, policy, pathToName each of which is defined optional. Byusing the example reference, it would be possible to perform security key

reference in a very flexible way. It would be possible to search for acertificate having a subjectAltName with a specific keyUsage. Figure 8(a)shows that the reference is encoded in XML while Figure 8 (b) shows thatthe reference is encoded in GSER.Hnh 8 cho thy mt v d nh vy. y, phn t GenericCertificateReference t cckhng gian tn dsext c s dng cung cp mt c ch tham chiu chung chung mthc hin CertificateMatch trong gii thiu X.509 [14]. tham chiu bao gm mt chui ccthuc tnh chng ch, serialNumber, t chc pht hnh, subjectKeyIdentifier,authorityKeyIdentifier, certificateValid, privateKeyValid, subjectPublicKeyAlgID,keyUsage, subjectAltName, chnh sch, pathToName mt trong s c xc nh tuchn. Bng cch s dng cc tham chiu v d, n s c th thc hin tham chiu an ninhquan trng mt cch rt linh hot. N s c th tm kim mt giy chng nhn c mtsubjectAltName vi mt keyUsage c th. Hnh 8 (a) cho thy rng tham chiu c mha trong XML trong khi hnh 8 (b) cho thy rng tham chiu c m ha trong GSER.

With the component matching enabled LDAP server, the GSER encodedreference value can be used as an LDAP assertion value in a componentfilter. With the ASN.1 awareness support, the LDAP server is now capable


36/40

of understanding the structure of the CertificateAssertion type whenconfigured with its ASN.1 definition. Because encoders / decoders forvarious encoding rules (GSER, DER, XER ...) are automatically generatedand integrated into the LDAP server, it is possible to use ASN.1 valuesencoded in those encoding rules as an assertion value in an LDAP searchoperation.Vi vic kch hot cc thnh phn ph hp my ch LDAP, GSER m ha gi tr thamchiu c th c s dng nh mt gi tr s xc nhn LDAP trong mt b lc thnh phn.Vi s h tr nhn thc ASN.1, cc my ch LDAP by gi l c kh nng hiu r cutrc loi CertificateAssertion khi cu hnh vi nh ngha ASN.1. Bi v b m ha / giim cho cc quy tc m ha khc nhau (GSER, DER, XER ...) c t ng to ra v tchhp vo my ch LDAP, n c th s dng ASN.1 m ha gi tr trong nhng quy tc mha nh l mt gi tr xc nhn trong mt thao tc tm kim LDAPWith the ASN.1 aware and component matching enabled LDAP server,flexible reference formats for X.509 certificates can now be defined in

ASN.1 to configure the LDAP server to understand the reference. Therequired matching rules, encoders, and decoders for the reference type will

be automatically generated and integrated to the LDAP server. Thisincreased flexibility will foster the flexible use of security token referencesin the LDAP server by making it easy to create and update referencesVi nhn thc ASN.1 v vic kch hot thnh phn ph hp vi Server LDAP, cc nhdng tham chiu linh hot cho chng ch X.509 c th c nh trong ASN.1 cu hnhcc Server LDAP hiu cc tham chiu. Cc quy tc ph hp vi yu cu, m ha v giim cho cc kiu tham chiu s c t ng to v tch hp my ch LDAP. vic tng tnhlinh hot ny s thc y vic s dng linh hot cc tham chiu th bi trong cc my ch

LDAP bng cch lm n d dng to v cp nht cc tham chiu7. Experimental ResultsWe used MindCrafts DirectoryMark [20] tools to generate the directoryentries and client scripts containing a list of LDAP operations. The clientscripts were run on an 8-way IBM xSeries 445 server with Intel Xeon2.8GHz processors and the directory server was run on an IBM xSeries 445server with 4 Intel Xeon 2.8Ghz processors and with 12GB of main memoryrunning SUSE SLES9 (Linux kernel version 2.6.5). We used thetransactional backend (back-bdb) of OpenLDAP version 2.2.22 togetherwith Berkeley DB 4.3 and OpenSSL 0.9.7 for the evaluation. Two differentsize DITs with 100K and 500K entries were used for evaluation. Ourintension of using two different size DITs was to observe the throughput ofslapd with and without memory pressure. With 100k entries, all the entrieswas able to be cached into the DB cache. On the other hand, with 500kentries, we observed that the server experienced a number of memoryswapping and disk I/O due to memory shortage. The directory was indexed


37/40

for cn, sn, email of inetOrgPerson and for serialNumber and issuer ofuserCertificate (or the corresponding extracted attributes in the case ofattribute extraction mechanism).chng ta s dng DirectoryMark ca MindCraft l cng c to ra cc mc nhp th mcv cc kch bn ca khch hng c mt danh sch cc hot ng LDAP. Cc kch bn ca

khch hng c chy trn my ch ca IBM xSeries 445 vi b vi x l 2.8GHz IntelXeon v my ch th mc chy trn mt my ch IBM 445 xSeries vi Intel 4 b vi xl Xeon 2.8GHz v vi 12GB b nh chnh chy SUSE SLES9 (nhn Linux phin bn2.6.5). chng ta s dng cc ph tr giao dch (back-BDB) ca OpenLDAP phin bn2.2.22 cng vi Berkeley DB 4.3 v OpenSSL 0.9.7 nh gi. Hai DITs kch thc khcnhau vi 100K v 500K mc nhp c s dng nh gi. N lc ca chng ta bngcch s dng hai DITs kch thc khc nhau quan st lu lng ca slapd c hockhng c b nh p sut. Vi mc nhp 100k, tt c nhng mc c th c lu tr vo bnh cache DB. Mt khc, vi mc nhp 500k, chng ta quan st thy rng cc my ch tri qua mt s trao i gia b nh v a I / O do thiu b nh. Th mc c lp chmc cho cn, sn, email ca inetOrgPerson v serialNumber v cng ty pht hnh ca

userCertificate (hoc trch xut cc thuc tnh tng ng trong trng hp ca c ch khaithc thuc tnh).

In the experiment, OpenLDAP stand-alone directory server, slapd, was usedas an LDAP certificate repository testbed for all three methods. Slapd as ofOpenLDAP version 2.2.22 supports both the component matching and thecertificate specific matching. The attribute extraction mechanism was tested

by using the XPS patch to OpenLDAP which was contributed to theOpenLDAP project by University of Salford. XPS was used to automaticallygenerate the DIT for the attribute extraction. The same version of slapd wastested for all three mechanisms for the LDAP certificate repositoryTrong th nghim, OpenLDAP my ch th mc c lp, slapd, c s dng nh mt kholu tr chng ch LDAP h thng th nghim cho c ba phng thc. Slapd caOpenLDAP phin bn 2.2.22 h c hai :cc thnh phn ph hp v cc thnh phn ph hpvi chng ch c th . C ch thuc tnh chit xut c th nghim bng cch s dngcc bn v XPS OpenLDAP c gp phn cho d n OpenLDAP i hc Salford.XPS c s dng t ng to ra cc DIT trch xut thuc tnh . Cng mt phin bnca slapd c th nghim cho tt c ba c ch i vi cc kho lu tr chng chLDAP


38/40

Fgure 9 (a) shows the throughput of three approaches, varying the number ofclients. With 100k entries, the peak throughput of component matching andattribute extraction mechanisms are almost the same. The certificate-syntax

specific matching (OpenSSL decoder) exhibits slightly lower performancethan the other two methods. We attribute the reason of lower throughput tolonger code path of slapd such as normalization and sanity checks ofassertion values when it uses the OpenSSL library. In order to observe the

behavior of the three methods in the presence of memory pressure, weincreased the number of entries to 500K and the database cache size isreduced from 1GB to 200MB. With this configuration, only small portion ofthe entries can be cached and hence the system suffers from frequentmemory swapping. Figure 9 (b) shows that the throughput of all threemethods are degraded significantly compared to Figure 9 (a). The peakthroughput of component matching is 3250 ops/sec, significantly degradedfrom 17,057 ops/sec with no memory constraint. The attribute extractionmechanism is hit by even further performance degradation than the othertwo mechanisms. This is because the number of entries becomes doubled byextracting attributes and by having them as separate entries subordinate tothe original ones. This results confirms that the component matching is asuperior approach to the attribute extraction with respect to performance aswell as to security and manageabilityFgure 9 (a) cho thy thng qua ba phng php tip cn, thay i s lng khch hng.Vi mc 100k, thng lng cao nht ca thnh phn ph hp v c ch thuc tnh trchxut l gn nh ging nhau. S ph hp vi c php c th ca chng ch (OpenSSL bgii m) th hin hiu sut hi thp hn so vi hai phng php khc. Chng ta cho lnguyn nhn ca thng lng thp lin quan n ng dn on code ca slapd di hnbnh thng v vic kim tra tnh ng n ca vic xc nhn cc gi tr khi s dng thvin OpenSSL. quan st hnh vi ca ba phng php trong s c mt ca p lc bnh, chng ta tng s lng cc mc n 500K v kch thc c s d liu b nh cachec gim t 1 GB n 200 MB. Vi cu hnh ny, ch phn nh ca cc mc c th c


39/40

lu tr v do b nh h thng b trao i thng xuyn chu . Hnh 9 (b) cho thy rngthng lng ca tt c ba phng thc suy thoi ng k so vi hnh 9 (a). thng lng caonht thnh phn ph hp l 3.250 ops / giy, xung mc ng k t 17.057 ops / giy vikhng b nh hn ch. C ch thuc tnh chit xut c nh hng bi suy thoi hiu sutthm ch cn xa hn so vi hai c ch khc. iu ny l do s lng cc mc tr nn tng

gp i bi cc thuc tnh chit xut v c chng nh l cc mc ring bit ph thuc vonhng bn gc. Kt qu ny xc nhn rng thnh phn ph hp l mt cch tip cn tthn chit xut thuc tnh lin quan n kh nng thc hin cng nh an ninh v qun l

8. ConclusionAlthough it is a general consensus in the PKI standardization working groupthat the component matching is a complete solution to the LDAP - PKIinteroperability problem, it was under debate that its adoption in LDAPservers might be slow and an alternative solution needed be pursued in theinterim. In this paper, we have presented the design and implementation ofthe component matching in OpenLDAP slapd. Our work provided a strong

evidence that the component matching can be implemented in pure LDAP-based directory servers without exploding complexity and degradingperformance. Our work also proposed a number of enhancements to thecomponent matching technology to improve performance and interoperability with legacy clients. In this paper, we also proposed the use of thecomponent matching enabled LDAP as a secure on-line certificate validation

protocol. We further demonstrated the usefulness of the componentmatching in WS-Security as a key application. As PKIs are being adopted inlarger scale and in more critical deployments, it becomes more important to

provide as complete a solution as possible, especially when it comes tosecurity. The component matching technology enables more secure andflexible implementation of LDAP certificate repositories for PKI withoutcompromising performanceMc d n c mt s nht tr chung trong nhm lm vic tiu chun ha PKI m thnhphn ph hp l mt gii php hon chnh ca cc vn v kh nng tng tc LDAP -PKI, n gy tranh ci rng n c thng qua trong cc my ch LDAP c th gy chmv gii php thay th cn thit c theo ui mt cch tm thi. Trong bi ny, chng ta trnh by vic thit k v trin khai ca cc thnh phn ph hp trong OpenLDAP slapd.Cng vic ca chng ta cung cp mt bng chng mnh m rng thnh phn ph hp cthc hin trong cc my ch th mc LDAP thun ty da trn m khng cn bng n

phc tp v lm gim hiu sut. Cng vic ca chng ta cng xut mt s ci tin cngngh thnh phn ph hp ci thin hiu sut v kh nng hot ng lin vi khch hngdi sn. Trong bi bo ny, chng ti cng xut vic s dng cc thnh phn no ph hpcho php LDAP l mt giao thc xc nhn giy chng nhn an ton trn mng. Chng tacng chng minh tnh hu ch ca cc thnh phn ph hp trong WS-Security l mtng dng quan trng. Nh PKI ang c p dng quy m ln hn v trong trin khaiquan trng, n tr nn quan trng hn cung cp l hon thnh mt gii php cng tt,c bit l khi ni n bo mt. Cc cng ngh thnh phn ph hp cho php thc hin an


40/40

ton hn v linh hot ca kho lu tr chng ch LDAP cho PKI m khng nh hng nhiu sut

Documents

do an dich_moi