Secure and Flexible Certificate Access in WSSecurity
through LDAP Component Matching
Sang Seok Lim
IBM Watson Research Center
P.O. Box 218
Yorktown Heights, NY 10598
slim@us.ibm.com
Jong Hyuk Choi
IBM Watson Research Center
P.O. Box 218
Yorktown Heights, NY 10598
jongchoi@us.ibm.com
Kurt D. Zeilenga
IBM Linux Technology Center
Redwood City, CA 94105
zeilenga@us.ibm.com
ABSTRACT
As an integral part of the Web Services Security (WS-Securi
ty), directory services are used to store and access X.509 cer-
ti¯cates. Lightweight Directory Access Protocol (LDAP) is
the predominant directory access protocol for the Internet,
and hence for the Web services. Values of LDAP attribute
and assertion value syntaxes, though de¯ned using ASN.1,
are encoded in simple octet string formats which generally
do not preserve the complete structure of the abstract val-
ues. As a result, LDAP matching rules for certi¯cates need
to be provided in a certi¯cate-syntax speci¯c way, while
X.500 matching rules can be constructed from structured
ASN.1 syntax de¯nition. Moreover, LDAP has traditionally
lacked the capability to make assertions against components
of values of complex syntaxes such as X.509 certi¯cates. The
WS-Security needs to be able to locate a target X.509 cer-
ti¯cate by matching against arbitrary certi¯cate components
in its security token references. Therefore, WS-Security re-
quires the directory server to be prepared with all the possi-
ble matching functions for maximum °exibility. This is very
cumbersome due to the lack of ASN.1 awareness in LDAP
server implementations. This led to development of reme-
dies such as the recently proposed Certi¯cate Parsing Server
(XPS). XPS extracts relevant components of the certi¯cate
and stores them in separate and searchable attributes. Due
to the signi¯cant downside of these remedies, we decided
to seek after an ASN.1 based Component Matching alterna-
tive in an attempt to make an LDAP directory server ASN.1
aware. With Component Matching and ASN.1 awareness,
LDAP can provide WS-Security with various matching rules
°exibly. In this paper, we describe our implementation of
the Component Matching and ASN.1 awareness in OpenL-
DAP Software. This paper will also describe the use of the
Component Matching technology in various security com-
ponents of Web Services, especially in the context of WS-
Security and XKMS. The experimental results show that
°exible and secure certi¯cate access can be accomplished
ACM Workshop on Secure Web Services, October 29,2004, Fairfax VA,
USA. Copyright 2004 ACM 158113973X/
04/0010....$5.00.
without sacri¯cing performance and manageability.
Categories and Subject Descriptors
H.3.5 [Information Storage and Retrieval]: Online In-
formation Services-Web-based services; C.5.5 [Computer
System Implementation]: Metrics|Servers
General Terms
Security, Design
Keywords
PKI, X.509 Certi¯cate, Certi¯cate Repository, Component
Matching, LDAP
1. INTRODUCTION
Public Key Infrastructure (PKI) [6] is an integral part of the
WS-Security speci¯cation [17] which provides an application-
layer security framework for Web services by including se-
curity information in SOAP (Simple Object Access Pro-
tocol) [1] messages. Portions of a SOAP message can be
signed in order to ensure integrity and can be encrypted to
ensure con¯dentiality. Certi¯cate Authority (CA) provides
the most universal form of the Security Token Service to
both Web service providers and requesters. The use of PKI
ensures the authenticity of the security tokens themselves.
The public key of a Web services entity is used to validate
the integrity and authenticity of SOAP messages which were
established by the corresponding private key and to encrypt
the contents of the SOAP messages.
X.509 certi¯cates [4] are often managed in the directory
and are accessed through standard directory access proto-
cols such as X.500 [11] Directory Access Protocol (DAP) [7]
and Lightweight Directory Access Protocol (LDAP) [5]. In
order to embed an X.509 certi¯cate as a security token in
a SOAP message, a Web service requester needs to retrieve
the X.509 certi¯cate from a CA. Alternatively, if the Web
service requester includes a certi¯cate URI as a reference to
the security token, it is a Web service provider who retrieves
the certi¯cate from the CA. Even when the certi¯cate is
embedded in the SOAP message, the Web service providers
may need to contact the certi¯cate repository in order to
verify whether the certi¯cate has been revoked by retrieving
a Certi¯cate Revocation List (CRL).
LDAP is predominantly being used as the directory access
protocol for the Internet. Compared to X.500 Directory
87
Access Protocol, LDAP renders lightweight directory service
by providing string-based encodings of names and attribute
values (hence of assertion values), simple protocol encoding,
direct mapping onto TCP/IP, and the reduced number of
operations. However, these simpli¯cations come at a price:
LDAP generally does not preserve the complete structure
of abstract values and the protocol and its implementations
are unable to harness the full power of the underlying ASN.1
data de¯nitions. Due to the use of specialized string-based
encodings for each syntax, adding support for new syntaxes
and matching rules requires new development e®orts. DAP
avoids these problems by the use of ASN.1 (Abstract Syntax
Notation One) [9] encoding rules, in particular the Basic
Encoding Rules [8].
Though these limitations were not viewed as a signi¯cant
problem during LDAP's early years, it is clear that a num-
ber of directory applications, such as PKI, are signi¯cantly
hampered by these limitations. For instance, in PKI, a cer-
ti¯cate needs to be located based upon the contents of its
components, such as serialNumber, issuer, key identi¯ers,
and subjectAltName [10]. LDAP search operations do not
understand the ASN.1 type of the certi¯cate attribute and
the assertion as de¯ned in [10], because attributes and asser-
tions in LDAP are encoded in an octet string with syntax
speci¯c encoding rules. Not only would it require excep-
tional e®ort to support matching rules such as certi¯cateM-
atch and certi¯cateExactMatch as de¯ned in [10], that e®ort
would have to be repeated for each matching rule introduced
to match on a particular component (or set of components)
of a certi¯cate. Because of the amount of e®ort each server
vendor must undertake to support each new rule, few new
rules have been introduced to LDAP since inception. Ap-
plications had to make due with existing rules.
Foreseeing the need to be able to add new syntaxes and
matching rules without requiring recoding of server imple-
mentations, the directory community engineered a number
of extensions to LDAP to address these limitations. The
Generic String Encoding Rules (GSER) [14] was introduced
and is now used in describing and implementing new LDAP
string encodings. GSER produces human readable UTF-
8 [22] encoded Unicode [19] character strings and supports
reuse of existing LDAP string encodings. The Component
Matching [15] mechanism was also introduced to allow LDAP
matching rules to be de¯ned in terms of ASN.1. Imple-
mentations may use automated systems to (statically and
dynamically) value parsing and matching functions. Addi-
tionally, Component Matching also introduces rules which
allow arbitrary assertions to be matched against selected
component values of complex data types such as certi¯cates.
For example, the Component Matching enables matching
against the selected components of a certi¯cate without the
need to de¯ne a speci¯c matching rule or requiring custom
codes to implement that matching rules for the certi¯cate
attributes.
Though the directory community saw GSER and Compo-
nent Matching as an eloquent solution to LDAP syntax and
matching rule limitations, there was some concerns, as most
LDAP server implementations were not ASN.1 aware, that
its adoption would be slow. To ful¯ll immediate needs of
PKI applications, another solution based upon component
extraction (or \data de-aggregation") was proposed and im-
plemented in Certi¯cate Parsing Server (XPS) [2]. While
some viewed this as being more pragmatic, as it shifted sig-
ni¯cant complexity from the server to the client and intro-
duced a number of security and management issues, it is con-
sidered by many to be not a workable solution for PKI appli-
cations (and certainly not a workable general solution to the
component matching problem). In the spring of 2004, IBM
undertook an engineering e®ort to provide ASN.1 awareness,
GSER, and component matching support in the OpenLDAP
Project's Standalone LDAP Daemon (slapd) (the directory
server component of OpenLDAP Software). We started from
implementing ASN.1 awareness in the server by providing an
automatic path to generate encoders and decoders for BER,
DER [8], and GSER from given ASN.1 data type de¯ni-
tions. In addition, this ASN.1 infrastructure automatically
generates the component extraction and matching routines
for the individual components of an attribute type. The
search ¯lter functions were modi¯ed to support Component-
Filter, ComponentAssertion, and ComponentReference. As
a result, it becomes possible to support complex matching
such as X.509 certi¯cateMatch with a Certi¯cateAssertion
syntax without manually de¯ning syntax speci¯c encodings
and matching routines.
We show an example of the °exible reference method with an
extension to <ds:X509Data> named, GenericCerti¯cateRef-
erence which is designed after the certi¯cateMatch of the
X.509 recommendation. De¯ning GenericCerti¯cateRefer-
ence was easy because the Component Matching infrastruc-
ture could automatically generate the corresponding certi¯-
cateMatch matching rules from the ASN.1 type speci¯ca-
tion. Web services can also use Component Matching in
a URI reference of Security Token Reference by specifying
the componentFilterMatch matching rule as the extended
matching rule in the LDAP URI. Component Matching pro-
vides XKMS with the interfaces to PKI, allowing it to lo-
cate and validate a certi¯cate °exibly. With the Component
Matching enabled LDAP server as the security token service,
the speci¯cation of token references will become very °ex-
ible. The Component Matching also ¯lls the security gap
in the certi¯cate access which required special Directory In-
formation Tree (DIT) structuring to avoid. The Component
Matching and GSER facilitate the °exible and extensive use
of security token references in SOAP messages.
This paper is organized as follows. Section 2 introduces
WS-Security and its use of X.509 certi¯cates as security to-
kens. Section3 presents an example X.509Data extension
element and how Component Matching technology is used
for XKMS. Section 4 introduces GSER and the Component
Matching. In Section 5, we present the design of the GSER
and Component Matching support in the OpenLDAP di-
rectory server. Section 6 shows experimental results of our
prototype implementation of LDAP component matching in
slapd. Section 7 concludes the paper.
2. WEB SERVICES SECURITY
2.1 SOAP and WSSecurity
SOAP (Simple Object Access Protocol) is a protocol for
invoking methods on servers, services, components, and ob-
jects [1]. It is a way to create widely distributed, complex
computing environments using an existing Internet infras-
88
01 <?xml version=”1.0” encoding=”utf-8”?>
02 <S:Envelope xmlns:S=http://www.w3.org/2001/12/soap-envelope>
03 <S:Header>
04 <wsse:Security>
05 <wsse:SecurityTokenReference wsu: Id=“#X509Token
06 <wsse:Reference
07 URI=“ldap://ldap.example.com/dc=example, dc=ibm???(userCertificate:componentFilterMatch:=
08 and:{ item:{ component “tbsCertificate.serialNumber”, rule allComponentsMatch, value 9453771 },
09 item:{ component “tbsCertificate.extensions.1.KeyUsage.value”, rule bitStringMatch, value ‘01000000’B }}”)>
10 </wsse:SecurityTokenReference>
11 <ds:Signature>
12 <ds:SignedInfo>
13 <ds:CanonicalizationMethod
14 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
15 <ds:SignatureMethod
16 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
17 </ds:SignedInfo>
18 <ds:SignatureValue>
19 Hp1ZkmFZ/2kQLXDJbchm5gK..
20 </ds:SignatureValue>
21 <ds:KeyInfo>
22 <wsse:SecurityTokenReference>
23 <wsse:Reference URI="#X509Token"/>
24 </wsse:SecurityTokenReference>
25 </ds:KeyInfo>
26 </ds:Signature>
27 </wsse:Security>
28 </S:Header>
29 <S:Body>
30 <m:GetLastTradePriceResponse xmlns:m=”http://example.com”>
31 <Price>34.5</Price>
32 </m:GetLastTradePriceResponse>
33 </S:Body>
34 </S:Envelope>
Figure 1: Web Service Request and Response with Security Token Reference.
tructure, enabling Web service developers to build Web ser-
vices by linking heterogeneous components over the Internet.
For interoperability over heterogeneous platforms, it is built
on top of XML and HTTP which are universally supported
in most services.
WS-Security [17] is recently published as the standard for
secure Web Services. It provides a set of mechanisms to
help Web Services exchange secure SOAP messages. WS-
Security provides a general purpose mechanism for signing
and encrypting parts of SOAP messages for authenticity and
con¯dentiality. It also provides a mechanism to associate se-
curity tokens with the SOAP messages to be secured. The
security token can be cryptographically endorsed by a se-
curity authority. It can be either embedded in the SOAP
message or acquired externally.
2.2 LDAPPKI
in WSSecurity
In WS-Security, a security token can be either embodied in
a SOAP message or acquired from an external service by
following SecurityTokenReference [17]. Signed security to-
kens such as X.509 certi¯cates are accessed through di®er-
ent forms of references de¯ned in the WS-Security standard
and in various security token pro¯les [18]. The security to-
kens can be retrieved and registered with the existing access
methods. Either standard access protocols such as LDAP
and HTTP or an ad-hoc access mechanism can be used to ac-
cess security tokens. XKMS (XML Key Management Spec-
i¯cation) [20] also provides a Web Service client which lacks
direct access to the security tokens with an o²oading mech-
anism. X.509 certi¯cates are the most universal form of the
security tokens which is well proven in the heterogeneous
and distributed network, the Internet. X.509 certi¯cates
were originally designed to be stored in directories. Hence,
directory access protocols such as X.500 and LDAP are the
most appropriate way to access them in terms of the naming
and information models and its powerful search capabilities.
In the following example scenario which illustrates an op-
erational °ow of accessing security tokens for a SOAP mes-
sage shown in Figure 1, it is assumed that the Web service
provider needs to contact the Security Token Service in or-
der to fetch and verify its security token. The °ow is as
follows:
1. The service requester constructs a SOAP message. It
contains a signature for the key elements of the mes-
sage. <ds:signature> is placed in the Security Header
block (lines 03 - 28 in Figure 1). In this scenario,
a X.509 certi¯cate is located in the external Security
Token Service. The reference to the external token
or the certi¯cate is included in the message within
<SecurityTokenReference> elements (line 05 - 10). The
constructed message is sent to the Web Service.
2. TheWeb Service fetches KeyInfo in line 21-25. It refer-
ences X.509Token, or ID which is de¯ned in line 05-10
as SecurityTokenReference. In this case, the reference
is an LDAP URI in line 07 - 09. In the URI, there
is a component ¯lter in which \tbsCerti¯cate.issuer"
and \tbsCerti¯cate.extensions.1.keyUsage.value" refer
to the corresponding components of a certi¯cate and
9453771 and \'01000000'B" are assertion values against
the components. More detailed explanation of the
component ¯lter will be described in Section 5.2.1.
89
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier EncodingType=“…#GSER”
ValueType=“…#GenericCertificateFields”
{ serialNumber 9453771, issuer {type cn, value ray} ,
keyUsage ‘100000000’B }
<wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
CertificateAssertion ::= SEQUENCE {
serialNumber [0] CertificateSerialNumber OPTIONAL,
issuer [1] Name OPTIONAL,
subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,
authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,
certificateValid [4] Time OPTIONAL,
privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL,
subject [11] Name OPTIONAL,
nameConstraints [12] NameConstraintsSyntax OPTIONAL
}
<wsse:SecurityTokenReference>
<ext:KeyIdentifier EncodingType=“…#XER”
ValueType=“…#GenericCertificateFields”
<CertificateAssertion>
<serialNumber>9453771</serialNumber>
<issuer>cn=ray</issuer>
<keyUsage>Signature</keyUsage>
</CertificateAssertion>
<wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
(b) XER
(c) GSER
(a) CertificateAssertion XML Schema
Figure 2: Certi¯cate Assertion Schema De¯nition and GenericCerti¯cateReference XER and GSER.
3. The Security Token Service searches for the certi¯-
cate according to the LDAP URI from the Web ser-
vice provider and returns the resulting certi¯cate as a
search result.
4. TheWeb service provider validates the <ds:Signature>
in the <wsse:Security> header and processes the SOAP
message to return the service result to the Web service
requester.
In the above scenario, the Web service retrieves the secu-
rity token stored in a directory through LDAP as a security
token access method. In order to retrieve the certi¯cate,
the Web service will send an LDAP request correspond-
ing to the reference URI. The Security Token References
can have various forms of references in addition to LDAP
URI. In case of X.509 certi¯cates, they can be referenced
by X509IssuerSerial, X509SubjectName, and X509SKI. The
<ds:X509Data> element of the <ds:KeyInfo> can also be
extended to represent elements from external namespaces.
2.3 LDAP Deficiencies for Certificate Access
Although WS-Security needs to be able to locate a certi¯-
cate by matching against arbitrary components of a certi¯-
cate, LDAP does not easily provide an universal matching
mechanism to the X.509 certi¯cate. In LDAP, attribute and
assertion values are represented in octet string. No struc-
tural information is stored along with them. A brute force
way to provide matching for complex attributes is to pro-
vide syntax speci¯c matching rules. For a X509IssuerSerial
reference for example, it is possible to write a special match-
ing function which matches the certi¯cate attribute against
the assertion value consisting only of issuer name and serial
number. Obviously, it will be too costly to de¯ne syntax
speci¯c matching rules for all possible references. In or-
der for an LDAP server to support X509SubjectName and
X509SKI, matching rules speci¯c to the references need to
be implemented. For a very °exible reference such as Cer-
ti¯cateMatch as de¯ned in X.509 recommendation [10], it
would be very di±cult to provide the corresponding match-
ing rule in LDAP. Moreover, it would be di±cult to cope
with changes such as certi¯cate extensions.
To address this mismatch between X.509 certi¯cate and
LDAP, the attribute extraction mechanism was recently pro-
posed in the Certi¯cate Parsing Server (XPS) designed by
the University of Salford [3]. In XPS, all the certi¯cate
attributes are extracted and stored as simple and search-
able LDAP attributes and matching is performed on the ex-
tracted attributes. Although it facilitates matching against
components of a complex attribute, it can be considered as
a suboptimal approach due to the following respects. First,
matching is performed on the extracted attributes but not
on the certi¯cate itself. Because the contents of the ex-
tracted attributes are mutable, there is a chance of return-
ing wrong certi¯cates to Web services. It is strongly recom-
mended for Web services to verify the returned certi¯cate
again. In order to minimize the security hole, the server ad-
ministrator must ensure the integrity of a certi¯cate and ex-
tracted attributes. Second, when there is more than one cer-
ti¯cate in a directory entry, one per key usage for example,
the Web services may be returned with multiple certi¯cates
even though they searched for certi¯cates having a speci¯c
key usage. The matched values control [10] does not solve
the problem, because matching is not performed on the cer-
ti¯cate itself. It is inevitable to restrict the Directory Infor-
mation Tree (DIT) structure in designing a certi¯cate DIT
to avoid an additional searching step in the Web services [2].
Third, the XPS does not facilitate matching against a com-
plex assertion value as in X.500 directory. It is not possible
to perform a °exible matching as in X.509 certi¯cateMatch
without making the LDAP directory server ASN.1 aware.
3. COMPONENT MATCHING
In order to overcome the mismatch between LDAP and the
requirement of °exible certi¯cate matching imposed by ad-
vanced applications like Web Services, we decided to pro-
vide 1) ASN.1-awareness and 2) Component Matching ca-
pabilities to an LDAP directory server. With the ASN.1-
awareness support for the LDAP server, ASN.1 values are
manifested within the server. It will be possible to use an
ASN.1 value in an assertion. Hence, matching can be per-
formed in an abstract level according to the corresponding
ASN.1 type de¯nition. With Component Matching, it be-
comes possible to match an assertion value against speci¯c
90
Certificate / CRL Repository (LDAP)
Registration
Authority (RA)
Certificate
Authority (CA)
XKMS Trust
Service
Client
Tier 0 RetrievalMethod
Tier 1 / 2
Locate / Validate
Key Mgmt
Certificate / CRL
Access
Publish
Certificate
Publish
Certificate / CRL
Management
Transactions
Management
Transactions
Registration
Revocation
Recovery
Figure 3: XKMS in PKI.
components of a complex attribute. For example, an infras-
tructure is provided to perform matching on an arbitrary
component of an X.509 certi¯cate, such as serialNumber,
issuer, keyUsage, and subjectAltName.
Compared to the XPS approach, our approach of providing
ASN.1 awareness and Component Matching has the follow-
ing advantages:
1. It does not store the X.509 attributes separate from
the certi¯cate itself. Therefore, it does not increase
storage requirements and does not open a potential to
the compromised integrity between a certi¯cate and
its extracted attributes.
2. Matching is performed directly on the contents of the
certi¯cate but not on the associated attribute's con-
tents. Even if there is more than one certi¯cate in a
user's entry, it can return only the matched certi¯cate
when it is used with the matched values control [10].
3. Flexible matching becomes possible because match-
ing between an attribute value and an assertion value,
both represented in ASN.1, will be provided.
3.1 Component Matching and Security Token
Reference
In the X.509 token pro¯le [18] of WS-Security, it is de¯ned
that the following three types of token references can be
used:
1. Reference to a Subject Key Identi¯er: the value of a
certi¯cate's X.509SubjectKeyIdenti¯er.
2. Reference to a Security Token: either an internal or
an external URI reference.
3. Reference to an Issuer and Serial Number: the certi¯-
cate issuer and serial number.
Because it is de¯ned to be extensible, any security token can
also be used with appropriate schemas. It is shown in Fig-
ure 1 that the <ds:X509Data> element of <ds:KeyInfo>
is used as the security token. <ds:X509Data> de¯ned in
[21] contains various references such as X509IssuerSerial,
X509SubjectName, X509SKI, and so on. With the ASN.1
awareness and the Component Matching support in an Open
LDAP directory server, these references can be used with-
out the need of implementing syntax speci¯c matching rules
for various types of the references. It is also possible to
use elements from external namespace in <ds:X509Data>
for further °exibility. Figure 2 shows one such an example.
Here, the GenericCerti¯cateReference element from dsext
namespace is used to provide a generic reference mecha-
nism which implements Certi¯cateMatch in the X.509 rec-
ommendation [10]. The reference consists of a sequence of
certi¯cate attributes, serialNumber, issuer, subjectKeyIden-
ti¯er, authorityKeyIdenti¯er, certi¯cateValid, privateKey-
Valid, subjectPublicKeyAlgID, keyUsage, subjectAltName,
policy, pathToName shown in Figure 2 (a), each of which is
de¯ned optional. By using the example reference, it would
be possible to resolve a security key reference in a very °ex-
ible way. For instance, searching for a certi¯cate having a
subjectAltName with a speci¯c keyUsage becomes possible.
Figure 2 (b) shows that the reference is encoded in XML
while Figure 2 (c) shows that the reference is encoded in
GSER.
With the ASN.1 aware and Component Matching enabled
LDAP server, the °exible reference format for an X.509 cer-
ti¯cate can now be de¯ned in ASN.1 with con¯guring the
LDAP server to understand the reference. The required
matching rules, encoders, and decoders for the reference
type will be automatically generated and integrated to the
LDAP server. This improvement in °exibility will foster the
°exible use of security token references in the Web Services
by making it easy to create and update references.
3.2 Component Matching and XKMS
Figure 3 illustrates a general PKI architecture which is com-
prised of CA, RA, and two types of end-entities. When a
PKI is used for Web Services, there are two types of PKI
clients: one directly accesses PKI; the other indirectly ac-
cesses it by using service proxies such as XML Key Man-
agement Speci¯cation (XKMS) [20] services which provide
clients with a well de¯ned interface to a PKI so as to hide
the complexities of the underlying PKI. The XML Key Infor-
mation Service Speci¯cation (X-KISS) is one of the services
provided by XKMS [20]. It de¯nes two key services: locate
and validate. In the following sections, it will be presented
how the Component Matching can be used in the X-KISS
services with respect to certi¯cates and CRLs access.
3.2.1 Certificate Access
Figure 4 shows an example X-KISS locate service request. In
the request, there is <QueryKeyBinding> which describes
how to bind this request to a desired public key. In the
example, <KeyUsage> and <ds:KeyInfo> are provided to
bind the request. A client using the XKMS service sends the
X-KISS Locate request shown in Figure 4. In response to
the request, the XKMS service needs to resolve the request
and then might contact an LDAP directory server to locate
the desired certi¯cate. In the example locate request, the
serial number in line 15-17 and the key usage in line 07 are
supplied by the client for <QueryKeyBinding>. With Com-
ponent Matching, the component ¯lter will be constructed
91
00 <?xml version="1.0" encoding="utf-8"?>
01 <LocateRequest xmlns:ds=http://www.w3.org/2000/09/xmldsig#
02 xmlns:xenc=http://www.w3.org/2001/04/xmlenc#
03 Id="I8fc9f97052a34073312b22a69b3843b6“
04 Service=http://test.xmltrustcenter.org/XKMS
05 xmlns="http://www.w3.org/2002/03/xkms#">
06 <QueryKeyBinding>
07 <KeyUsage>Signature</KeyUsage>
08 <ds:KeyInfo>
09 <wsse:SecurityTokenReference>
10 <ds:X509Data>
11 <ds:X509IssuerSerial>
12 <ds:X509IssuerName>
13 o=IBM,c=US
14 </ds:X509IssuerName>
15 <ds:X509SerialNumber>
16 9453771
17 </ds:X509SerialNumber>
18 </ds:X509IssuerSerial>
19 </ds:X509Data>
20 </wsse:SecurityTokenReference>
21 </ds:KeyInfo>
22 </QueryKeyBinding>
23 </LocateRequest>
Figure 4: Example XKMS Locate Service Request.
from the request by the XKMS services as shown in Figure 5.
The component reference \tbsCerti¯cate.extension.*" refers
to all extensions of the certi¯cate of which KeyUsage is one
extension. In the value, \extndID 15" is the object identi¯er
of a KeyUsage and \'100000000'B" is used to check if a cer-
tain bit(the ¯rst bit for signature) is set. The corresponding
component ¯lter of Figure 5 enables the XKMS service to
¯nd a certi¯cate of an issuer for a signature purpose only. If
the client uses GenericCerti¯cateReference explained in the
previous section and the Component Matching is supported
in an LDAP directory server, the XKMS service can use ar-
bitrary ¯elds of a certi¯cate in order to construct component
¯lters to process the locate request.
3.2.2 CRL Access
The XKMS service also provides an X-KISS Validate Ser-
vice with which a client using XKMS services can check the
status of a public key by sending some of <ds:KeyInfo> el-
ements in <QueryKeyBinding> in line 08-21 of Figure 4.
For instance, if it checks the validity of a X.509 certi¯cate
using CRLs, the client may send <X509Data> containing
<ds:X509SerialNumber> 9453771 </X509SerialNumber> in
<QueryKeyBinding>. In response to the request, the XKMS
service might choose to use either CRL based validation or
Online Certi¯cate Status Protocol (OCSP) [16].
A certi¯cate revocation list (CRL) [6] can be generated and
distributed periodically by the CA, making it available on
the Internet by typically using an LDAP directory server or
aWeb server. Because a CRL contains the list of multiple re-
voked certi¯cates, it can become quite large and burdensome
to transmit it over the Internet. To alleviate this problems,
OCSP was proposed to provide a timelier and more e±cient
status mechanism. The XKMS service can speak to OCSP
responders which can check the status of a certi¯cate. The
OCSP responder returns the status (either good, revoked, or
unknown) of a requested certi¯cate. With OCSP, the XKMS
service does not need to download and scan the CRL, which
are burdensome to the service.
We conceive that Component Matching can be used as an
(userCertificate:componentFilterMatch
:= and:{
item:{
component “tbsCertificate.serialNumber”,
rule IntegerMatch,
value 9453771
},
item:{
component “tbsCertificate.extension.*”,
rule allComponentsMatch,
value {extnID 15, extnValue ‘100000000’B}
}
}
)
Figure 5: Example Component Filter.
alternative to OCSP. The CRL is a sequence of pairs of a
revoked certi¯cate's serial number and a revoked time [6].
In order to check the status of a certi¯cate, the XKMS ser-
vice needs to construct a component assertion by using the
serial number of the certi¯cate as shown in the upper item
of Figure 5 and send it to the LDAP directory server. Then
the server will perform Component Matching on the CRL
against the assertion to ¯nd the asserted certi¯cate in the
CRL. By using the Component Matching based CRL vali-
dation, the whole CRLs is not required to be downloaded
to the XKMS service. An LDAP server already has been
widely used for distributing certi¯cates and CRLs. Hence,
if the server can perform validity checking over LDAP as
well, it will be a very practical and e±cient alternative to
the OCSP which needs additional protocol layer, or and an
OCSP responder.
4. COMPONENT MATCHING AND GSER
The attribute syntaxes of X.500 are de¯ned in ASN.1 types.
Basically, the types are constructed structurally from basic
types to composite types. Every ¯eld of an ASN.1 type is a
component. Component Matching [15] de¯nes how to refer
to a component within an attribute value by retrieving the
structural information of an ASN.1 type and how to match
the component against an assertion value. Matching rules
are de¯ned for the ASN.1 basic and composite types. It also
de¯nes a new assertion and ¯lter targeted for a component.
These de¯nitions are based on ASN.1 so that they can be
applied to any syntax, as long as the syntaxes are speci¯ed
in ASN.1.
A native LDAP encoding does not represent the structure
of an ASN.1 type. Instead, it is represented either in octet
string or in binary. With the LDAP encoding, as a result,
it is di±cult to contain the structural information of ASN.1
type in its representation. In order to solve this problem,
Legg [14] recently proposed GSER (Generic String Encod-
ing Rules). Component matching uses GSER as its basic
encoding for the component ¯lter. GSER generates a hu-
man readable UTF-8 character string encoding of a given
ASN.1 speci¯cation. It de¯nes UTF8 string encodings at
the lowest level of primitive ASN.1 types such as INTE-
GER, BOOLEAN, and STRING types and then it builds
up more complex ASN.1 types such as SEQUENCE and
SET from the lowest level. Thus, the structural information
of an ASN.1 speci¯cation is maintained in encodings so that
it can be recovered in the decoding process. By using GSER
to store attribute values instead of the native LDAP string
encoding, LDAP server will become capable of identifying
92
{ version 2,
serialNumber 12345 ,
signature { algorithm 1.2.840.113549.1.14, parameters NULL},
issuer {{type cn, value IBM trust} , {type o, value IBM},{type c, value US}},
validity {notBefore {2004 01 13 18 59}, notAfter {2005 01 13 18 59} },
…
}
GSER encodings
TBSCertificate :: = SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublickKeyInfo subjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIOMAL
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL
extensions [3] EXPLICIT Extensions OPTIONAL
}
typedef struct TBSCerticate{
AsnInt version;
AsnInt serialNumber;
struct AlgorithmIdentifier* signature;
struct Name* issuer;
…
}
C internal data structure
Encoding
EncTBSCertificate(…)
Decoding
DecTBSCertificate(…)
ASN.1 Compiling
Figure 6: ASN.1 TBSCerti¯cate speci¯cation, its compiler output, and example GSER encodings.
the structure of ASN.1 speci¯cation of the attribute types.
Furthermore, a component ¯lter of an LDAP request is also
encoded in GSER. Hence, GSER is an essential mechanism
to ASN.1 awareness and Component Matching. GSER en-
coding can also be used in an assertion to facilitate a very
°exible and abstract matching of two ASN.1 values.
Figure 6 shows the ASN.1 type speci¯cation of TBSCerti¯-
cate and its GSER encodings. TBSCerti¯cate is de¯ned as
SEQUENCE so that there are curly braces at the beginning
and at the end of its GSER encodings. It has version, se-
rialNumber etc. as its components inside of SEQUENCE.
Within the braces in the encoding, there is version and 2, or
its value, followed by a comma which separates the encod-
ing of the subsequent ¯eld. GSER de¯nes each basic type's
encoding and then combines them structurally to more com-
plex ones by using \f", \," and \g". On the other hand, a
native LDAP encoding does not have any uniform rule to
construct the structural information of attribute value in
it.
5. COMPONENTMATCHINGIMPLEMENTATION
IN OPENLDAP
An ASN.1 compiler translates ASN.1 modules into C data
structures representing ASN.1 and their encoding / decod-
ing routines as illustrated in Figure 7. We extended the eS-
NACC ASN.1 compiler to implement the GSER backend in
addition to the originally supported BER and DER [12]. It
also generates component equality matching rules and com-
ponent extract functions which will be discussed in the rest
of the section in detail. In order to facilitate the integration
of the newly de¯ned syntaxes without the need of rebuild-
ing the slapd executable, the generated data structures and
routines are built into a module which can be dynamically
loaded to slapd.
The rest of the section will provide a detailed description
of the component matching in two steps. After describing
how to make the OpenLDAP directory server ASN.1 aware,
the description of component ¯lter processing, aliasing, and
ASN.1 types
GS/B/DER decoder
Component equality
matching rule
Component extract
function
OpenLDAP
Server (slapd)
Dynamic Module
Load
C Data structures
Automatic
generation
eSNACC
Compiler
GSER back-end
Figure 7: Input and Output of an eSNACC Com-
piler.
component indexing will be presented. Then, the overall
operational °ow of Component Matching will be described.
5.1 ASN.1 Awareness
5.1.1 eSNACC Compiler
We have implemented a GSER backend for the extended
eSNACC compiler. GSER can be used as an LDAP en-
codings for newly de¯ned attribute types. With GSER,
string-based LDAP encodings can maintain the structures
of their corresponding ASN.1 types. The assertion values
in the component ¯lter are also represented in GSER and
the GSER decoders are used to decode them into their in-
ternal representations. Figure 6 shows the example C data
structure for a TBSCerti¯cate ASN.1 type and its corre-
sponding GSER encodings. Generated C data structure for
the ASN.1 type has data ¯elds corresponding to components
of the ASN.1 type. Once the C data structure for TBSCer-
ti¯cate is instantiated, it can be converted into GSER en-
codings by EncTBSCerti¯cate() and the encodings can be
decoded into the C data structure by DecTBSCerti¯cate().
The eSNACC compiler also generates matching rules and
extract functions automatically which will be further dis-
cussed in the next subsection.
93
Table 1: Attribute Aliasing Table.
Alias Attribute Aliased Attribute Component Reference Matching Rule
x509certi¯cateSerialNumber userCerti¯cate tbsCerti¯cate.serialNumber integerMatch
x509certi¯cateIssuer userCerti¯cate tbsCerti¯cate.issuer distinguishedNameMatch
5.1.2 Component Representation of ASN.1 Types
A new data structure of slapd is needed to represent an
attribute value at its component level because the original
data structure for attributes does not contain the structure
information of an ASN.1 type in its representation. Every
¯eld of an ASN.1 type is a component which is addressable
by a component reference. In our implementation, the com-
ponent data structure consists of two parts: one to store
the value of the component; the other to store a component
descriptor which contains information on how to encode, de-
code, and match the value of the component.
The data structure of a component appears as a tree which
keeps the structural information of the original ASN.1 spec-
i¯cation using nodes and arcs. Each component node of
the tree not only has data values but also represents the
structural information of the given ASN.1 speci¯cation by
having links to subordinate nodes. In the tree, any node
can be referenced by a component reference in order to per-
form matching on the corresponding component. Hence, we
need a function to traverse the tree and locate the refer-
enced node. The ASN.1 compiler also generates component
extractor routines for this purpose.
5.1.3 Syntax and Matching Rules
An attribute is described by an attribute type in LDAP. An
attribute type contains two key ¯elds which help to de¯ne
the attribute as well as rules that it must follow. The ¯rst
¯eld is a syntax which de¯nes the data format used by the
attribute type. The second ¯eld is a matching rule which is
used by an LDAP server to compare an attribute value with
an assertion value supplied by the LDAP search or compare
operations. Attributes must include the matching rules in
their de¯nition. At least, an equality matching rule should
be supported for each attribute type. From the viewpoint of
an LDAP server, an ASN.1 speci¯cation de¯ning a new at-
tribute type requires a new syntax and its matching rule to
be de¯ned in it. To fully automate the component match-
ing in which the composite attribute types are de¯ned in
ASN.1, we extended the eSNACC compiler to generate the
basic equality matching rule of a given ASN.1 type, or all-
ComponentMatch matching rule speci¯ed in RFC 3687 [15].
The allComponentMatch matching rule evaluates to true
only when the value of the referenced component of the
attribute and that of ComponentAssertion are the same.
It can be implemented by performing matching from the
top-most component which is identi¯ed by the component
reference recursively down to the subordinate components.
The generated matching function of each component can be
overridden by other matching functions through a matching
rule re¯nement table. Therefore, it is possible that a syn-
tax developer can replace the compiler-generated matching
functions with existing matching functions of slapd which
might be more desirable. In order to support this re¯ning
mechanism, slapd checks if a matching function is overrid-
den or not by looking up the re¯nement table, whenever it
(userCertificate:componentFilterMatch
:= not:item:{
component “tbsCertificate.serialNumber”,
rule IntegerMatch,
value 9453771
}
)
Component Reference
Component Assertion
Component Filter
New Matching Rule
Figure 8: Example Component Filter.
is executed.
5.2 Component Matching
5.2.1 Component Assertion and Filter
RFC 3687 [14] de¯nes a new component ¯lter as the means
of referencing a component of a composite attribute and as
the means of representing an assertion value for a composite
attribute types. Component assertion is an assertion about
the presence or the values of components within an ASN.1
value. In the component assertion, there are three key ¯elds:
² Component Reference: speci¯es which component of
an attribute value will be matched against an assertion
value.
² Matching Rule: speci¯es which matching rule will be
used to perform matching on the values.
² Value: An assertion value in GSER.
Component ¯lter is an expression of component assertions,
which evaluates to either TRUE, FALSE, or Unde¯ned af-
ter performing matching. Figure 8 illustrates an exam-
ple component ¯lter. The component reference \Certi¯-
cate.serialNumber" identi¯es one component in the Certi¯-
cate attribute value. In the component reference, \." means
identifying one of components subordinate to the preceding
component. In the component assertion, rule is followed by
an integerMatch matching rule [11] which will be used to
compare the following assertion value with the referenced
component of the attribute value. The routines required to
support the component ¯lter and the component assertion
were hand-coded while the routines for the component asser-
tion values are automatically generated from a given ASN.1
type.
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 changes will be minimal, if at all, be-
cause the component ¯lter can be speci¯ed by using the ex-
isting extensible matching rule mechanism of LDAPv3 and
the component assertion value is represented as the text
centric GSER encoding rules. In particular, the clients that
94
Table 2: Decoder Performance Comparison.
d2i X509() ASN.1 ASN.1
Decoder Decoder for CM
Time (usec) 32.74 40.20 72.00
accept search ¯lters as strings require no changes to utilize
component matching other than ¯lling in the necessary com-
ponent ¯lter as the search ¯lter. However, for those clients
who have search ¯lters hard coded in them, we propose an
attribute aliasing mechanism which maps a virtual attribute
type to an attribute component and a component matching
rule, and a matching rule aliasing mechanism which maps a
virtual matching rule to a component assertion.
Attribute aliasing registers a set of virtual attributes to an
LDAP server. The virtual attributes themselves ¯nd corre-
sponding matching rules and component references by look-
ing up an attribute alias table. The example attribute alias
table is shown in Table 1. x509certi¯cateSerialNumber at-
tribute is aliased to userCerti¯cate.tbsCerti¯cate.serialNumb
er with the integerMatch matching rule. Hence, the ¯lter
(x509certi¯cateSerialNumber=12345) is considered equiva-
lent to (userCerti¯cate:ComponentFilter:=item:component
tbsCerti¯cate.serialNumber, rule integerMatch, value 12345).
With an attribute aliasing, clients only have to form sim-
ple assertions to utilize component matching. A matching
rule alias works in a similar way. An alias matching rule is
mapped into the corresponding a component reference and
a matching rule.
5.2.3 Putting It All Together
The overall °ow of acquiring security tokens in Web services
with Component Matching is as follows. First, the ASN.1
speci¯cation of a X.509 certi¯cate is compiled and the gen-
erated routines are loaded into the LDAP server. Once they
are loaded successfully, Component Matching on the certi¯-
cate can be performed in the server. Then, the Web Service
requester sends the Web Service provider a SOAP message
which contains SecurityTokenReference. URI reference was
taken as an example in the following discussion. The Web
service provider fetches the SecurityTokenReference from
the message and performs an LDAP search based on the
LDAP URI in it. The search ¯lter can contain the compo-
nent assertion against the corresponding component of the
certi¯cate. Accepting a component search request, certi¯-
cates in the LDAP server are decoded by the corresponding
DER decoder to construct a component tree of the certi¯-
cate. It has all certi¯cate attributes as de¯ned in the X.509
recommendation. The incoming component ¯lter is parsed
to obtain the component assertion value and the component
reference by the GSER decoder for the ¯lter. The compo-
nent extractor extracts the referenced component from the
component tree which is speci¯ed by the component refer-
ence in the component ¯lter. The component assertion value
is decoded by the corresponding GSER decoder for the ex-
tracted component. At this point, we have obtained the
ASN.1 internal representation of both the component asser-
tion value and the returned certi¯cate component. Matching
is performed on these two internal data structures and the
matched certi¯cate is returned to theWeb Service provider.
6. PERFORMANCE CONSIDERATIONS
The benchmarking was performed with a 40,000 entry DIT.
Using an LDAP benchmark in ruby scripts [13], only read
operation was performed ¯rst on the entries with varying
base DNs in the LDAP search requests. The read bench-
mark was made to test how fast data could be read from
slapd. The machine running slapd has two 2.40GHz Hy-
perthreading Intel Xeon CPUs and 1.5Gbytes memory. The
slapd was con¯gured with a BDB backend. First, we mea-
sured the performance of eSNACC compiler generated DER
decoders as compared to that of the openssl decoder, d2i X509()
function (manually written certi¯cate parsing function). Ta-
ble 2 shows how much time both decoders took to decode
an example X.509 certi¯cate generated by openssl.
d2i X509 took 32.74 usec to decode a certi¯cate. The com-
piler generated DER decoder took 40.20 usec in case of not
allocating component descriptors which is not out side of
the pure decoding process. The compiler generated decoder
took 7.46 usec longer as compared to d2i X509(). It is be-
cause the decoder allocated memory not only for ASN.1 val-
ues but also for the component data structures of each ¯elds
of the certi¯cate.
We also integrated the compiler generated decoders into
slapd and performed searching by Component Matching.
We measured the average time to search for an entry con-
taining the target certi¯cate, varying the number of concur-
rent clients. The search scope is base and a component ¯lter,
\(userCerti¯cate:componentFilterMatch:=item:component
\tbsCerti¯cate.serialNumber", rule integerMatch, value 945
3771)" is used in the search. As the number of concurrent
clients is increased from 1 to 8, the overall searching time
of both cases were also increased from 1 msec to 6 msec
approximately. When the number of concurrent clients is
1, Component Matching (CM) takes 1.2 msec and d2i X509
takes 1.18 msec. When the number of concurrent client be-
come 8, CM takes 5.91 msec and d2i X509 takes 6 msec.
The time di®erence between the Component Matching and
d2i X509 is very small and can be considered to be within
the experimental error bound. It is because the decoding
itself is only small portion of a search operation. It only
accounts for 4-7% of overall search time. We also performed
subtree search and it appeared that the average searching
time of CM was only slightly higher than that of d2i X509.
The overheads of parsing component ¯lters can be removed
by using attribute and matching rules aliases.
Overall searching time is heavily dependent on other factors
such as ¯lter parsing, indexing, and caching rather than de-
coding. By the experiment, It was proven that a °exible and
secure way of accessing a certi¯cate and CRL was achieved
without performance degradation.
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 in-
dexing is performed by generating a hash key value of the
attribute syntax, matching rule, and the attribute value and
maintains the list of IDs of those entries having the matching
value in the set of attribute values of the indexed attribute.
The component indexing can be speci¯ed in the same way
as the attribute indexing, except that the component ref-
95
erence is used to specify which component of a composite
attribute to be indexed. If the referenced component is a
basic ASN.1 type, the indexing procedure will be the same
as the attribute indexing. The indices for the referenced
component are accessed through a hashed value of the cor-
responding syntax, matching rule, and value in the index
¯le for the referenced component of the composite attribute.
In OpenLDAP, the indexing of the composite component is
centered on the GSER encodings of the component value.
The hash key of a component value is generated from its
GSER encodings together with its syntax and matching rule.
For the SET and SET OF constructed types, it is required
to canonicalize the order of the elements in the GSER en-
codings before generating the hashed key value. For <all>
component reference of SET OF and SEQUENCE OF. it is
needed to union the indices for each value element of SET
OF and SEQUENCE OF.
7. CONCLUSION
WS-Security is a key protocol for securing SOAP message
exchanges. It de¯nes token references in order to acquire se-
curity tokens internally and externally. An X.509 certi¯cate
is an universally used security token and is usually stored
and retrieved via LDAP. The X.509 certi¯cate pro¯le of WS-
Security and XML Signature standards provides a rich set of
reference methods for the X.509 certi¯cate in a °exible and
extensible way. Component Matching and ASN.1 awareness
in LDAP are very e®ective mechanisms to cope with this
°exibility and extensibility.
This paper presented the design of the Component Match-
ing in the OpenLDAP directory server in the context of
WS-Security. It is described the ¯rst implementation of the
component matching and ASN.1 awareness in a pure LDAP
based directory server. In order to provide a fully auto-
mated infrastructure, we extended an ASN.1 compiler to
automatically generate the component extraction / match-
ing routines and encoders / decoders of BER, DER, and
GSER for a given ASN.1 type. To make the server un-
derstand an incoming ComponentFilter in GSER format,
the search ¯lter processing was modi¯ed to support Compo-
nentFilter, ComponentAssertion, and ComponentReference
as well. For backward compatibility in the case where the
search ¯lters are hard coded to client applications, we also
provide an alias mechanism for the attribute names and the
matching rules. According to the experiments, the perfor-
mance of the prototype system which integrated compiler-
generated decoders was proven to be competitive to that of
the hand-optimized ones. We conclude from the experiment
that °exible and secure certi¯cate access can be achieved
without losing performance and manageability.
8. REFERENCES
[1] D. Box and D. Ehne. Simple object access protocol
(SOAP). W3C Note, May 2000.
[2] D. W. Chadwick. De¯ciencies in LDAP when used to
support PKI. Comm. of the ACM, 46(3), March 2003.
[3] D. W. Chadwick, E. Ball, and M. Sahalayev.
Modifying LDAP to support x.509-based PKIs. In
17th Annual IFIP WG 11.3 Working Conference on
Database and Applications Security, August 2003.
[4] W. Ford and D. Solo. Internet x.509 public key
infrastructure certi¯cate and certi¯cate revocation list
(CRL) pro¯le. RFC 3280, 2002.
[5] J. Hodges, R. Morgan, and M. Wahl. Lightweight
directory access protocol (v3): Technical speci¯cation.
RFC 3377, September 2002.
[6] R. Housley, W. Ford, W. Polk, and D. Solo. Internet
X.509 public key infrastructure certi¯cate and CRL
pro¯le. RFC 2459, January 1999.
[7] ITU-T Rec. X.511, The directory: Abstract service
de¯nition, 1993.
[8] ITU-T Rec. X.690, ASN.1 encoding rules:
Speci¯cation of basic encoding rules (BER), canonical
encoding rules (CER), and distinguished encoding
rules (DER), 1994.
[9] ITU-T Rec. X.680, Abstract syntax notation one
(ASN.1): Speci¯cation of basic notation, December
1997.
[10] ITU-T Rec. X.509, The directory: Public-key and
attribute certi¯cate frameworks, March 2000.
[11] ITU-T Rec. X.500, The directory: Overview of
concepts, models and service, February 2001.
[12] R. Joop. Snacc 1.2rj.
http://www.fokus.gmd.de/ovma/freeware/snacc/
entry.html.
[13] A. Krennmair and R. Lischka. Testing OpenLDAP
server, March 2004.
[14] S. Legg. Generic string encoding rules. RFC 3641,
October 2003.
[15] S. Legg. X.500 and LDAP component matching rules.
RFC 3687, February 2004.
[16] M. Myers, R.Ankney, A.Malpani, and C.Adams.
Internet X.509 public key infrastructure online
certi¯cate status protocol - OCSP. RFC 2560, June
1999.
[17] OASIS. Web services security: SOAP message security
1.0 (WS-Security 2004). OASIS Standard 200401,
March 2004.
[18] OASIS. Web services security: X.509 certi¯cate token
pro¯le. OASIS Standard 200401, January 2004.
[19] The Unicode Consortium. The Unicode Standard,
Version 4.0. Addison-Wesley, Boston, 2003.
[20] W3C. XML key management speci¯cation (XKMS).
W3C Standard, March 2001.
[21] W3C. XML - signature syntax and processing. W3C
Standard, February 2002.
[22] F. Yergeau. UTF-8, a transformation format of ISO
10646. RFC 3629, November 2003.
96
[返回] W3CHINA.ORG讨论区 - 语义网·描述逻辑·本体·RDF·OWL →
W3CHINA.ORG讨论区 - Web新技术讨论 → 『 Web Services & Semantic Web Services 』 → Secure and Flexible Certificate Access in WSSecurity
(订阅本版)
2006/12/30 17:32:00
新浪微博
Secure and Flexible Certificate Access in WSSecurity
