Relying Party Credentials Framework

Electronic Commerce Research, 4: 23–39 (2004) 2004 Kluwer Academic Publishers. Manufactured in the Netherlands.

Relying Party Credentials Framework

AMIR HERZBERG ∗ [email protected] University

YOSI MASS ∗∗ [email protected] Haifa Research Lab

Abstract

We present architecture for a relying-party to manage credentials, and in particular to map different credentialsinto common format and semantics. This will allow use of simple, widely available credentials as well as moreadvanced credentials such as public key certificates, attribute certificates and ‘negative’ credentials (which resultin reduced trust) such as certificate revocation lists (CRL). The core of the architecture is a Credential Managerwho collects credentials, and maps them to common format and semantics.

1. Introduction

Trust and assessment of quality and qualifications are critical for secure business and com-merce. A relying party decides whom to trust, and estimates quality, by direct evaluationand inspection, and by credentials from third parties. A credential is an assertion by anissuer of some attributes of the subject of the credential. Credentials may include reviews,recommendations, certifications, historical records, and so on. It is up to the relying partyto interpret the credentials, and in particular, some credentials may result in reduced trustor quality assessment. Indeed, some credentials may assert ‘negative’ attributes of theirsubject, e.g., a convictions record. The relying party should also validate the authentic-ity of the credential, e.g., by checking a digital signature over it; notice that the securitymechanism used to authenticate the credential (e.g., signature) is not a part of the creden-tial itself. In this broad interpretation, credentials form the basis for many business (andprivate) processes. Most of these processes are manual, and based on physical (paper)credentials.

With the growth of electronic commerce, relying parties often want to make trust andquality decisions using automated systems (programs), with electronic credentials. Manysystems use only very simple forms of electronic credentials, such as the result of a lookupin a database kept by the issuer, based on user-id/password identification. However, it iswell recognized that digitally signed credentials such as public key certificates, attributecertificates and certificate revocation lists are essential for more efficient and secure elec-tronic commerce.

∗ http://amir.herzberg.name/. Part of work done while with IBM.∗∗ http://www.haifa.il.ibm.com

24 HERZBERG AND MASS

In this work, we propose that the relying party uses a credential management moduleor service, to collect all credentials and map them into common format and type (seman-tic attributes). The credentials may be of different kinds and numerous formats, and areretrieved using a variety of different protocols and methods. The main credential kinds are:

• Identity public key certificates, signed by a Certificate Authority (CA). Identity certifi-cates link the subject name (or other identifier) with a specific public key, and possiblysome other attributes (e.g., in extension fields). For X.509 certificates, subject name isspecified in the distinguished name field and/or in the alt-name extension. The mostpopular format for public key certificates is X.509, but there are others (e.g., SPKI); fur-thermore X.509 certificates, as of version 3, have facilities for arbitrary extensions, andthe relying parties must deal with many different profiles and proprietary extensions.

• Non-identity public key certificates. These are certificates, which do not include an iden-tifier, but only a public key (or hash of it) and attributes of the owner of the private keycorresponding to the public key. One reason for not including an explicit identifier is topreserve anonymity of the requesting party; in this case, the requesting party uses com-pletely different certificate for each request to prevent linkage (see, e.g., [Brands, 5]).Other reasons for not including explicit identifiers are when the issuer does not knowthe identity or prefer not to include it, e.g., to avoid liability. There are several formatsfor non-identity certificates including SPKI, KeyNote, and non-standard usage of X.509certificates.

• Attribute certificates are a signed message linking an identifier with some attributes. Anattribute certificate normally would not contain the public key of the subject (or hashof it), therefore another method should be used to validate the identifier correspondswith the subject making a specific request. Typically, an attribute certificate contains theidentity of a CA and the serial number of a public key certificate issued by that CA tothe subject.

• Digitally signed or otherwise authenticated documents, e.g., PICS rating [Resnick andMiller, 26] or an entry from a database (e.g., ‘Dun & Bradstreet’ record as in [1]). Anespecially simple and common case is the use of the entry from a local (membership)database as a credential of an entity, after this entity was (locally) authenticated usinguser-id and password. Another common case is query to a database service (e.g., via theWeb), using an identifier such as URL or company/individual name. Obviously, there isa multitude of different formats and variants of such credentials.

The plurality of different kinds, formats, types, and sources of credentials create a seri-ous challenge to the relying parties. We propose architecture for credentials management,which collects credentials (from various sources) and maps them to a common format andtype (semantics), to simplify decision making by the relying party. This architecture allowsthe relying party to take advantage of different credentials, with differences ranging fromdifferent formats, different sources and access methods, to different semantics (such asdifferent measure scales for the same attribute, e.g., weight). The collected credentials, aswell as the decision-making mechanisms in the relying party, can use any of the different

RELYING PARTY CREDENTIALS FRAMEWORK 25

approaches proposed and available. The services of the credential manager will simplifydecision-making based on credentials. These services include:

• Collecting credentials from different sources, using multiple protocols.

• Mapping multiple formats of credentials into a simple common format and interface.

• Extraction, from credentials, of the semantics relevant and understood by the relyingparty applications.

• Credential management, including storage, updates and revocation checking.

In order to simplify and focus on a credential management, our work does not addressthe actual authentication and identification of the requesting party, and in particular, we donot discuss how to confirm that the requesting party is the subject of specific credentials.This confirmation is necessary, to prevent against a corrupted party making a request, withcredentials belonging to a more trusted or reliable party. When the credential include thepublic key of the subject, such confirmation can be easily done over an insecure network,by checking for digital signature on the request or using an authenticated channel such asTLS/SSL or IPSEC [25; Harkins and Carrel, 16; Dierks and Allen, 8]. When a human,physically adjacent to secure confirmation facilities, makes a request, the credential mayidentify its subject by biometrics (picture, fingerprint, etc.) or by name or identifier inconjunction with identity card or device. This confirmation is outside the scope of thispaper.

We present only high-level architecture of the credential manager. We expect follow upwork to transform this high level architecture into practical, widely accepted and standard-ized framework.

1.1. Identifiers, names and keys in credentials

There is considerable confusion and controversy about identifiers in credentials (and cer-tificates). Following [Clarke et al., 7], we find it useful to distinguish between two kindsof identifiers: names and keys, as they serve two related but different purposes:

• A name allows the Relying party to identify other references to the same subject, usingthe same name, in credentials or databases. The relying party may also remember thename for possible future reference, e.g., to create historical records or to sue the subject.The name may have legal or human-recognizable meaning, such as registered name,official company name, or logotype [Santesson, 28; Josang et al., 23]. Names should beuniquely resolvable, to make sure that all references are to the same subject. However,the same subject can have multiple names (often of different types).

• A key is a value that allows the relying party to directly identify the subject of the cre-dential or a message coming from the subject. In particular, a public key of the subjectin a credential (certificate) is a key, as it allows the relying party to validate the subject’ssignature on a request or to identify the subject by sending it an encrypted challenge.A picture or fingerprint is also a key, as the relying party can use them to identify the


subject by direct observations (biometric identification). A key is supposed to be uniqueto the subject (to allow identification); therefore, some keys can also be used as a name(e.g., when appearing in multiple credentials).

Identity public key certificates bind between a key (public key) and the subject name(sometimes also alternate names).

Every name should have well defined interpretation and in particular be from a well-defined set. In X.509 certificates, names are usually specified in the Distinguished Namefield, and/or in the SubjectAltName extension. Names can be from a ‘flat’ globalnamespace, such as social security number. More often, names are defined by speci-fying a namespace and a particular name within that namespace. In particular, X.509Distinguished Names are built as a sequence of ‘relative distinguished names,’ graduallyfocusing from a global namespace to a particular namespace, and the last relative distin-guished name assumed unique within the last namespace (e.g., C = US/L = NY/O =NYPD/OU = SOHO/CN = John Doe). The names in SPKI consist of a namespace fol-lowed an identifier, where the namespace is identified by a key or by a (shorter) SPKIname.

1.2. Credential attributes and types

In simple scenarios, credential issuers are closely coordinated with credential relying ap-plications, and the applications can use the credential directly. This may be achieved bystandardizing the credentials. This is done in the PKIX standards for public key certificates[Housley et al., 19], which define exact certificate format with exact encoding (both basedon [20]) and specific ways for encoding identifiers and attributes in the certificates. Wecomment that the usage of PKIX is still quite complex, in particular since there are mul-tiple ways to specify attributes—as fields, attributes of the subject’s Distinguished Namefield, extensions, privileges within extensions, and more. Furthermore, [Housley et al., 19]sometimes permits the same attribute to be specified in multiple locations. For example,the e-mail address of the subject may be specified as attribute EmailAddress of the subjectdistinguished name, although the standard specifies that in new implementations the e-mailaddress must be specified as rfc822Name in the subject alternative name field. As a result,even when the credential issuers and credential relying applications use the same exactstandard for credentials, there may be substantial complexity in processing the attributesin the credential due to potential ambiguity and alternative mappings, as well as to havingsome attributes as fields, some as attributes, some as extensions, and so on. The creden-tial manager maps all the attributes to a simple, uniform structure, simplifying the relyingapplications.

In many realistic scenarios, a credential relying application may need to be able to handlecredentials from multiple issuers—possibly even for the same subject. The different issuersmay use slightly or dramatically different credential formats. Consider even a very basiccase of two issuers using PKIX X.509 certificates, but with different private extensions, us-age of options, or semantic meanings as defined in the Certificates Policy Statement (CPS)[Chokani and Ford, 6]. It is quite possible that the two certificates actually carry the same


semantic attributes, however they are encoded differently. We say that the two certificatesare of different type1. A credential type identifies a particular set of attributes as well astheir precise semantic meanings. The Credential Framework that we offer provides a gen-eral mechanism for mapping between compatible credential types. Even if used simply toimplement the CPS mappings defined by the PIKS and X.509 standards, this will alreadyremove complexity from the relying applications.

In order to identify which mapping should be used, it is easier if the credential typeis known. We consider credentials with an explicitly known type, as well as credentialswhere the type is not known. When the type is not known, the framework will attempt toidentify the type; afterwards, it will use mappings among identified credential types. Theframework will also provide the type identifier to the relying application in a standard way,which will make it easier for the application to use multiple credential types.

The use of credentials from multiple potential issuers, for the same subject or for differ-ent subjects, may be further complicated if the credentials may use different formats. Asmentioned above, credentials may be, in addition to public key certificates, also attributecertificates, revocations, or other credentials such a PICS [Resnick and Miller, 26] rating ora record from a database (e.g., the ‘Dun & Bradstreet’ record returned by Eccelerate [1]).Furthermore, there are multiple formats for public key certificates, ranging from differentX.509 extensions, to completely different certificate formats such as PGP, SPKI, Policy-Maker and KeyNote. The framework maps different credential formats to one commonand simple format.

1.3. Related works

The most well-known and deployed approach to public key infrastructure is the X.509standard [20], recently revised and extended [21]. The X.509 approach focus on identitybased public key certificates. It assumes a universal convention for selecting distinguishednames (DN), which are unique identifiers based on the subject name. The distinguishednames consist of several components or attributes, one of them being the common name—which would typically be the first, middle and last name of the subject (if a person). Theother components of the distinguished name should ensure uniqueness, as common namesare clearly not unique. Notice that this requires careful selection of the other identifiers inthe distinguished name, and in fact in many implementations some of the common nameentries had to be artificially modified to ensure that the distinguished name will be unique,resulting in common names like John Smith1.

A bigger problem with the traditional X.509 approach results from the implicit require-ment that a certificate issuer is responsible for correct identification, with potential liabilityfor damages from wrong identification [Ellison and Schneier, 11]. This became a concern,and indeed many companies refrained from issuing certificates (e.g., to employees). At-tribute certificates [Ellison et al., 10; Farrell and Housley, 12; 21] provides a mechanism toprovide a credential by referring to a public key certificate, thereby allowing a company toat least issue a credential (attribute certificate), using public key certificate issued by someother CA. However, the introduction of attribute authorities introduces additional complex-


ity to the relying party, even if using only X.509 certificates, since now attributes of thesubject are defined in both attribute certificates as well as in (multiple parts of) public keycertificates. Our approach could be used to help simplify the use of X.509 certificates, aswell as to allow support for additional forms of credentials.

Recent works, in particular [Blaze et al., 3, 4; Ellison, 9; 30] introduce new formats forpublic key certificates. These works are complementary to the present manuscript sincethey do not propose methods to deal with different credential (and certificate) formats. Twoother important differences: these works consider only public-key certificates, not generalcredentials; and their certificates contain authorization information (which operations areallowed to the subject), while we define credentials as containing simply attributes assertedby the issuers. This last difference is conceptual rather than technical, since clearly one canencode permissions in a certificate field for attributes and vice versa.

Part of the motivation of [Blaze et al., 3, 4; Ellison, 9; 30] is to change the X.509 namingmechanisms. They suggest that names should only be unique with respect to a given issuer,and do not necessarily have to have global meaning (and therefore liability). In fact, in thisapproach, the name field in a certificate becomes just a convenience and an option, and thesubject is really identified by possessing the private key corresponding to the public key inthe certificate.

Another problem with traditional X.509 approach lies with the implicit assumptionthat there exist a hierarchy of certificate (and attribute) authorities, and relying partiesknow and trust the root CA of this hierarchy. A very different approach is taken byPGP [Zimmerman, 33], where certificates define a ‘web of trust’ and there is no cen-tral CA. We share the view advocated by many [Abdul-Rahman and Hailes, 2; Blazeet al., 3, 4; Ellison, 9; Ellison et al., 10; Ellison and Schneier, 11; Gerck, 13; Herzberget al., 18; Josang, 22; Kohlas and Maurer, 24; 27; 30; 31; Zimmerman, 33], thata relying party may not necessarily completely trust the issuers of the credentials. Instead,these works advocate a model where the relying application may need multiple credentialsto make its decisions, and has a non-trivial policy for the necessary credentials. Our work isa follow-up to our work in [Golan et al., 14; Herzberg et al., 18; 31], where we developedtools and algorithms to determine if a subject has the right set of credentials (from properlytrusted issuers) according to a given policy.

In an earlier version of this paper [Herzberg and Mass, 17], we introduced a simple XMLsyntax for credentials. In this version, we show how encode credentials using the SAMLsyntax [Hallam-Baker and Maler, 15], which is in advanced stages of definition. TheSecurity Assertion Markup Language (SAML) is an XML-based syntax for specifyingsecurity assertions about subjects. A SAML assertion can contain information aboutauthentication of the subject, authorization decision (whether the subject is allowedcertain operation on resources), and attributes (attributes) of subjects. Credentials, as wedefined them, are assertions by the issuer only about attributes of the subject. Our asser-tions therefore do not include authentication and authorization information. The SAMLeffort does not address the credential management issues addressed by the architecture inthis paper.


Figure 1. Relying party credential management architecture.

2. Relying party credential management architecture

We propose that the relying party use an architecture as illustrated in Figure 1. The coremodule is the Credential Manager. The manager receives requests for resolving credentialsfrom the appropriate module of the relying party (either directly from the relying applica-tion, or from the trust management or access control modules). The request includes anidentifier of the subject, instructions on where to search for credentials, and optionallyan initial credential(s), e.g., a public key certificate. The initial credentials are typicallyreceived from with some request (e.g., connection). The Credential Manager is not con-cerned with validating that the requestor has the right to the credentials—that should bevalidated thru independent means, such as validating a digital signature on the request, orauthenticating the requestor, e.g., using SSL. After the credential relying application ortrust manager receives the credentials collected and processed by the credential manager,it may submit another request to the credential manager, e.g., searching for credentials ofan issuer of some of the credentials returned by the credentials manager.

In a typical Web deployment, a request is received at the (web) server from a client.If SSL client authentication is used, the server will receive a certificate from the client2,otherwise the server may receive some other identifier for the client (e.g., user name and/ore-mail address3), and potentially a password. The Credential Manager is called with thereceived identifier and credential (certificate).

The Credential Manager has three main modules and functions:

• The collector collects (additional) relevant credentials. In many cases, the requestingparty may not present all of his credentials together with the request. In others, the re-lying party is evaluating the credentials for another party on its own initiative, withoutreceiving a request (e.g., when the relying party wants to contact one of list of poten-tial partners). In particular, in the typical case when the subject is authenticated using


SSL or TLS client or server authentication [25; Dierks and Allen, 8], then only onecertificate (chain) is sent from the subject to the relying party performing the authenti-cation. Furthermore, there may be credentials that the subject may not even be awareof (e.g., review by a referee trusted by the relying party), or ‘negative’ credentials, pro-viding unfavorable statements and attributes, that the subject may not willingly disclose.The collector module of the credential manager will automatically collect such missingcredentials as described below. The collector also performs two related administrativefunctions:

– Check for revocations of credentials. Many types of credentials may be revoked ormodified. Certainly, the subject cannot be trusted to provide information on revoca-tions or (disadvantageous) modifications to its credentials.

– Cache credentials to speed up processing. To improve efficiency, the collector moduleof the credential manager may store received credentials.

• The format converter converts all the credentials into simple, uniform format. Thisallows credential relying applications to be oblivious to the specific format and evenmethod of a credential. For example, the logic in an e-marketplace application thatdeals with a membership request may only care if the subject is an employee of a mem-ber company, but not if this information was received by a public key certificate, by anattribute certificate, by e-mail to the company or by a direct query. In a previous ver-sion of this paper [Herzberg and Mass, 17], we defined such a simple XML syntax; inthe current version, we use the recently published Secure Assertion Markup Language,SAML [Hallam-Baker and Maler, 15].

• The semantics converter converts the attributes in the credentials to these known to therelying application. This includes removing irrelevant attributes, renaming attributes,changing scales (e.g., to metric scale), and removing credentials which have unknownattributes marked critical.

We describe each of the modules of the credential manager in the following sections.

3. Credential Collector

The first operation of the credential manager is to collect credentials for the subject. Thecredential collector module handles this, upon receiving a request from the relying ap-plication. The request indicates the subject (and possibly one or more known credentialsfor it), list of repositories to be searched for credentials, and options. The options includemaximal time for cached credentials, maximal number of credentials, and limits on theissuers and types of credentials.

To collect credentials, the Credential Collector will contact one or several credentialcollector adapters, or simply adapters, as illustrated in Figure 2 (additional collectors maybe needed for other protocols and repositories). The Credential Manager uses a table itmaintains mapping repositories to available adapters. For performance, it also uses a localcache of credentials, subject to the options in the request.


Figure 2. Credential Collector module.

Adapters may use different mechanisms appropriate to collect different kinds of creden-tials, from different sources. Some of these are:

• Adapters are likely to request public key and attribute certificates from a repositoryidentified by the subject and given in the request to the Credential Manager, and/or frompredefined central repositories.

• Adapters may try to collect credentials from central repositories, which keep credentialsfor many entities. This approach is needed whenever the subject may be unaware of thecredential, and even more if the credential is ‘negative’—such as a certificate revocationlist or an unfavorable product review. As described in [27], this approach is also usefulto find a chain of certificates (or credentials) from the issuers trusted by the relying partyto the issuers of credentials to the subject.

• Adapters may try to collect credentials using general-purpose search engines, for cre-dentials that will have well defined and accepted format. This is particularly useful fornegative credentials.

• Adapters may use predefined gateways to provide credentials. A typical role for a gate-way may be to provide interface to a database, using a public key certificate that includesan identifier of an entry in the database. In this case, the client is authenticated using apublic key certificate (e.g., using SSL/TLS). Then, the certificate, or just the identifier,is sent (by the collector) to the gateway. The gateway performs an appropriate queryon a database, using the identifier, and returns the record. This mechanism is used byeccelerate.com to provide subject records from ‘Dun & Bradstreet’s database [1].

• Adapters may contact a server for the subject using secure mechanisms, providing thesubject identifier, and receive back the credentials of that subject. To limit exposure ofthe credentials, the subject may provide the relying party with a password necessary toreceive the credentials from the server. A ‘use once’ password is also possible, whichwill be used only for the specific transaction, and communicated securely between the


Figure 3. Credentials conversions.

subject and her server. A ‘use once’ password may be sent by the adapter or received bythe adapter from the server, in which case it is returned to the relying party application(which should then use it to authenticate the request).

All adapters encode the credentials they collected in a general XML document syntax,to allow uniform processing of the credentials. In the next section we discuss possibleencoding, in particular using the Security Assertion Markup Language (SAML [Hallam-Baker and Maler, 15]), and possible automated conversion tools that further simplify theprocessing of the collected credentials.

4. Credentials encoding and conversions

The conversion of credentials is the central service of the Credential Manager. The conver-sion receives credentials with different formats and types, and makes them all available viaa common, simplified interface, also mapping them to the types known to the credentialrelying application. See Figure 3.

The conversion consists of two stages, each in separate module: the format converterand the semantic converter. The format converter receives credentials in different formats,encoded as stings in a simple document format; it seems reasonable for this format to bethe same as the detailed credential format, e.g., using the same (subset of) SAML [Hallam-Baker and Maler, 15], but with the entire input credential (in different formats) encoded asa string. The format converter performs the mostly ‘mechanical’ transformation of extract-ing the attributes from the credentials and encoding them as SAML (XML) elements, tosimplify further processing. There is very limited significance to the particular format (weused a different format in [Herzberg and Mass, 17]).

The second stage is the semantic converter; it focuses on extracting the attributes andcredential type meaningful to the relying application. In the next section, we explain howwe use the Security Assertion Markup Language (SAML), and in the following sections,we describe the format converter and the semantic converter.

4.1. Credential content and encoding

Our goal is to automatically process and handle a large variety of different credential types.For that, we identify the different fields, which are relevant to any credential, and define


generic encoding for credentials with these fields. Different encodings may be used withthe architecture; to illustrate, we suggest how each field may be encoded using the SAML[Hallam-Baker and Maler, 15] <Assertion> element (in earlier version we used differentencoding [Herzberg and Mass, 17]). Below we list the different fields and suggestions fortheir encoding:

• Type and attributes—this field contains the attributes (properties), which the credentialasserts for the subject, and the type or format of the credential. The credential type,when known, defines the expected attributes in the credential. The credential type alsodefines the meaning of attributes (unless they are from a more general namespace, usedby multiple credential types). When the credential is in some non-SAML format, and itsexact type and attributes are not yet determined, this field includes the format by name(e.g., ‘PKIX’ or ‘SPKI’) and there is only one attribute, including the entire credential(in standard textual encoding). Suggested SAML encoding: encode the attributes andcredential type using SAML <AttributeStatement> element. This element will containone or more <Attribute> elements. For credentials imported from different formats,there will be an <Attribute> element with attributes AttributeNamespace = ‘Formats’,AttributeName as the name of the format, e.g., AttributeName = ‘PKIX’, and <At-tributeValue> element containing the imported credential as a string. If the importedcredential is in XML, then the <AttributeValue> can contain it directly as XML ele-ment. If the credential type is known, there will be an <Attribute> element with at-tributes AttributeNamespace = ‘Type’ and the type of the credential as the value of theattribute AttributeName, e.g., AttributeName = ‘Rating’ (and no <AttributeValue> el-ement). The other <Attribute> elements will contain the different attributes, with theappropriate AttributeNamespace (often the credential type).

• Subject—the subject of the credential. The Subject field can contain one or more namesand/or keys for the subject. Suggested SAML encoding: encode the subject name(s) andkey(s) used to confirm its identity, using one or more SAML <Subject> element(s). Thiselement already contains appropriate sub-elements for subject name and key, namely<NameIdentifier> and <SubjectConfirmation>, respectively.

• Issuer key (credential confirmation method)—the key with which the credential wasverified (typically the public key of the issuer or its hash). Suggested SAML encoding:SAML does not include a natural element for this value. However, SAML allows arbi-trary extensions in the <Statement> element, and it suggested to use such an extensionto define an <Issuer> element similar to the <Subject> element (defined in SAML).A natural way to add the issuer key is to place it in <IssuerConfirmation> elementwithin <Issuer> element, defined like the <SubjectConfirmation> element (which is inSAML, placed in the <Subject> element).

• Issuer name—this is the name of the issuer, allowing search for credentials for the issuerby name (but these credentials must also include the Issuer key to be safely associatedwith the same issuer). Suggested SAML encoding: SAML defines an Issuer mandatoryattribute to the <Assertion> element, designated for the name of the issuer. Therefore,whenever a well-defined string representation for the name is available, it should beplaced in the Issuer attribute of <Assertion>. However, a more natural place would


be in a <NameIdentifier> element within the <Issuer> element discussed above. Thiswould also allow support for multiple names and name formats.

• Capture and conversions history—identifies the procedure(s) used to capture the cre-dential, i.e. how it was received (e.g., certificate received from web server using SSL, orquery against a database). Also lists the procedures used to convert the credential fromits initial type to its present type. The capture and conversion history field may be used,for example, to avoid an unreliable conversion. Suggested SAML encoding: SAML doesnot include a natural element for this value. One possible encoding is as an additionalextended <Statement> element, and another is to specify the capture and conversionhistory as part of the <IssuerConfirmation> element.

5. The Format Converter

The Format Converter is a module that accepts different credential formats and convertsthem into a common interface, e.g., to the SAML format. More precisely, the inputto the Format Converter is a simple SAML document, which contains a single attributewhose name is the format of the credential and whose value is the credential (in that non-SAML format). The Format Converter will invoke a format converter module to extractthe SAML-defined attributes from the credential, using one of the available modules (fromdifferent formats). New format converter modules may be added to support additional andnew credential formats. See Figure 4.

Some credentials are composed by standard encoding of a certain format. Examplesof popular encodings are BER and DER (typically used to encode X.509 certificates) andBASE64 (used to provide printable encoding for different content), In this case, the FormatConverter may first remove the encoding. For example consider a BER (Basic EncodingRule) encoded PKIX X.509 certificate which is given as input to the format converter, asin Figure 5. BER encoding is the standard encoding for ASN.1 (Abstract Syntax NotationOne), the syntax for X509v3 certificates. The Format Converter can use a BER to XMLconverter, e.g., from the IBM Tokyo Research Lab XML Security Suite [32]. The outputof the BER to XML translator is an XER (XML Encoding Rule) format, which describesthe X.509 certificate in XML. The next converter extracts the PKIX-defined attributes fromthe certificate fields and extensions, and exposes them in the respective SAML elementsfor simpler, uniform access and processing (in the figure we showed only a few of theattributes, such as the Issuer Distinguished Name, the Subject element and an attributecontaining the SubjectAltName).

For another example, showing format conversion for SPKI certificate, see Figure 6.Similar format converters can handle credentials extracted from databases, as PICS la-

Figure 4. Format Converter.


Figure 5. Format conversion for PKIX/X.509 certificate.

bels, XML documents or otherwise (e.g.„ proprietary formats, e.g., the one for ‘Dun &Bradstreet’ records used by [1], or HTML page).

6. The Semantic Converter

The second and last conversion step is the Semantic Converter. The purpose of this con-version is to convert a SAML credential into another CML credential in which the fieldsare now understandable by the relying party.

We give now some semantic converter examples. The first example is a user’s e-mailaddress. In an X509v3 certificate, this field may appear in the subjectAltName field as anrfc822Name while in another XML signed document it may appear under some EMAILtag. Without the semantic converter, an application that wants to use the e-mail address willhave to understand various credential formats. With the semantic conversion, the e-mailaddress appears in a fixed field, hence it easy to be used by an application.

Another example is an AC (Attribute Certificate), which describes a role of a user par-ticipating in a marketplace. One AA (Attribute Authority) may issue values ‘buyer’ and‘seller’ in a field named ‘role’ while another AA may issue values ‘customer’ and ‘vendor’in a field named ‘member type.’ The semantic converter converts these two formats intosome common format known to the relying party so that both AC are mapped to the samefield.


Figure 6. Format conversion for SPKI certificate.

Another example is a Trust Policy engine as in the Trust Establishment toolkit [31]. Thetoolkit allows a company to define a policy for mapping users to roles based on credentials.The policy language is rule based and it filters credentials assuming that each credentialhas some known type field (e.g., a recommendation credential, a credit history credentialetc). The semantic converter can be used to assign a type to each credential even if thecredential does not come with a predefined type field.

A natural question is: why do we need this conversion? Why can’t we decide on someprofile for each type of credential? The answer is that it is hard to decide on some commonformat that is acceptable on every issuing authority. Moreover, many credentials are ex-tracted from legacy databases or issued by existing authorities, and it is almost impossibleto force common fields.

The reason we believe the semantic converter will achieve the desired interoperabilitybetween the various credential formats is since it converts credentials only for a specificrelying party which defines the conversion rules for itself and it does not try to coordinateall the issuing authorities in the world.

6.1. The Semantic Converter architecture

We expect that there would be many credential types, defined by different issuers for dif-ferent reasons. We expect that some of these will become popular and therefore converters


Figure 7. Semantic Converter.

among them may become available. However, with a large and dynamic set of creden-tial types, it is not reasonable to develop one program to convert any given credential to acommon known credential type. Instead, the semantic converter manager has interface tomultiple semantic converter modules, and uses the appropriate module for each conversion.See Figure 7.

Each Semantic Converter Module (SCM) has to first register with the manager and hasto implement some defined SPI (Service Provider Interface). On registration, the SCMinforms the manager which credential types it knows to accept as inputs, and which cre-dential types it knows to generate as outputs. The manager constructs a graph representingknown conversions, with the credential types as nodes, and an directed edge connectingfrom one credential types to another, when a converter from the first to the second isknown. When a new SAML credential is given to the manager, the manager searchesfor the shortest path from the type of the given credential to any of the types known to therelying party, and invokes the corresponding Semantic Converter Modules.

7. Summary

Credentials, and in particular public key certificates, are essential for establishing rela-tionships and trust among entities communicating via open networks such as the Internet.However, there are many different kinds of credentials, using different repositories, re-trieval methods and protocols, formats, security mechanisms and attributes. The resultingcomplexity is one of the obstacles limiting the deployment of secure electronic commerceand in particular of public key certificates and applications using them.

We propose an architecture where a dedicated module manages collection of credentialsand maps them into a common format. The module itself is not too complex, as it is brokeninto three fairly simple sub-modules, each performing one simple task: collection, formatconversion, and semantic conversion. Relying party applications using the module aresubstantially simplified, by receiving all the credentials in a standard format with (only)well defined properties. A prototype implementation of this architecture is included in theTrust Establishment [31] toolkit.


Acknowledgments

We thank Tom Gindin for helpful discussions and comments, and providing [21]. Thanksalso to the anonymous referees for their helpful comments and suggestions.

Notes

1. The term ‘profile’ is also sometimes used for this purpose, however we prefer the term ‘type’ as ‘profile’ isalso used for other certificate-related purposes.

2. Most web servers automatically verify the certificate chain presented by the client conforms with a policy(in particular, has a trusted root CA). This may cause a failure if the client has only certificates from CAnot known in advance to the server, before the credential manager is asked to collect credentials for thisunknown CA. To allow users to receive certificates also from unknown issuers, disable this verification. If thisis impossible, a workaround is to allow certificates from a ‘dummy’ root CA, whose private key is not secret;this will allow the certificate the pass the automatic verification by the server, and then the credential managerwill collect the necessary additional credentials for the same public key used for authentication.

3. Notice that an e-mail address may be weakly authenticated by the server sending it a challenge and receivinga response, before calling the credentials manager.

References

[1] “A Technical Overview of the eccelerate.com Solution,” http://www.Eccelerate.com.[2] Abdul-Rahman, A. and S. Hailes. (2000). “Supporting Trust in Virtual Communities.” In Proceedings of

the Hawaii International Conference on System Sciences, Maui, Hawaii.[3] Blaze, M., J. Feigenbaum, J. Ioannidis, and A. Keromytis. “The KeyNote Trust-Management System.”

http://www.cis.upenn.edu/~angelos/keynote.html.[4] Blaze, M., J. Feigenbaum, and J. Lacy. (1996). “Decentralized Trust Management.” In Proc. of the 17th

Symposium on Security and Privacy, pp. 164–173.[5] Brands, S. (1999). “Rethinking Public Key Infrastructure and Public Key Certificates—Building in Privacy.”

ISBN 90-901-3059-4, Ponsen & Loijen BV, Ph.D. Dissertation, Technical University Eindhoven.[6] Chokani, S. and W. Ford. (1999). “Internet X.509 Public Key Infrastructure: Certificate Policy and Certifi-

cation Practices.”[7] Clarke, D., J.-E. Elien, C. Elison, M. Fradette, A. Morcos and R.L. Rivest. (2000). “Certificate Chain

Discovery in SPKI/SDSI.” Manuscript.[8] Dierks T. and C. Allen. “The TLS Protocol Version 1.0, RFC 2246.” IETF Network Working Group, January

1999.[9] Ellison, C. (1999). “The Nature of a Usable PKI.” Computer Networks 31, 823–830.

[10] Ellison, C., B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. (1999). SPKI Certificate Theory.[11] Ellison, C. and B. Schneier. (2000). “10 Risks of PKI.” Computer Security Journal 16(1), 1–7.[12] Farrell, S. and R. Housley. (2001). “An Internet Attribute Certificate Profile for Authorization.”

http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-09.txt.[13] Gerck, E. (2000). “Overview Of Certification Systems: X.509, PKIX, CA, PGP and SKIP.” The Bell

1(3), 8.[14] Golan, I., A. Herzberg, Y. Mass, and O. Green. (2001). “Efficient Trust Policy Evaluation.” Manuscript.[15] Hallam-Baker, P. and E. Maler (eds.). (2002). Assertions and Protocol for the OASIS Security Assertion

Markup Language (SAML), http://www.oasis-open.org/committees/security/docs.[16] Harkins, D. and D. Carrel. (1998). “The Internet Key Exchange (IKE).” IETF Network Working Group,

RFC 2409, November 1998.


[17] Herzberg, A. and Y. Mass. (2001). “Relying Party Credential Framework.” In Topics in Cryptography—CT-RSA, Lecture Notes in Computer Science, Vol. 2020, pp. 328–343.

[18] Herzberg, A., Y. Mass, J. Mihaeli, D. Naor, and Y. Ravid. (2000). “Access Control Meets Public KeyInfrastructure, or: How to Establish Trust in Strangers.” In Proc. of IEEE Symp. on Security and Privacy,Oakland, CA.

[19] Housley, R., W. Ford, N. Polk, and D. Solo. (1999). “Internet X.509 Public Key Infrastructure: Certificateand CRL Profile.”

[20] ITU-T Recommendation X.509 (1997): “Information Technology—Open Systems Interconnection—TheDirectory: Authentication Framework.”

[21] ITU-T Recommendation X.509 | ISO/IEC 9594-8: “Information Technology—Open Systems Interconnec-tion—The Directory: Public-Key and Attribute Certificate Frameworks”.

[22] Josang, A. (1999). “An Algebra for Assessing Trust in Certification Chains.” In J. Kochmar (ed.), Proceed-ings of the Network and Distributed Systems Security Symposium (NDSS’99), The Internet Society.

[23] Josang, A., M.A. Patton, and A. Ho. (2001). “Authentication for Humans.” In B. Gavish (ed.), Proceedingsof the 9th International Conference on Telecommunication Systems (ICTS2001), Cox School of Business,Southern Methodist University, Dallas.

[24] Kohlas, R. and U. Maurer. (2000). “Reasoning about Public-Key Certification—on Bindings between Enti-ties and Public Keys.” IEEE Journal on Selected Areas in Communications 18(4).

[25] Netscape, SSL 3.0 Specification, http://home.netscape.com/eng/163/index.html.[26] Resnick, P. and J. Miller. (1996). “PICS: Internet Access Controls Without Censorship.” Communications

of the ACM 39(10), 87–93.[27] Reiter, M.K. and S.G. Stubblebine. (1997). “Path Independence for Authentication in Large-Scale Systems.”

In Proc. of 4th ACM Conf. on Computer and Comm. Security, pp. 57-66.[28] Santesson, S. (2001). “Logotypes in X.509 certificates.” IETF PKIX Working Group internet draft.[29] SET. Secure Electronic Transaction, http://www.setco.org.[30] Simple Public Key Infrastructure (15), http://www.ietf.org/html.chapters/15-chapter.

html.[31] Trust Establishment toolkit, http://www.haifa.il.ibm.com/trusted.html.[32] XML Security Suite, http://www.alphaworks.ibm.com/tech/xmlsecuritysuite.[33] Zimmerman, P. (1995). The Official PGP User’s Guide, Cambridge: MIT Press.

Relying Party Credentials Framework

Documents

Transcript of Relying Party Credentials Framework