Capability Card: An Attribute Certificate in XML From: http://www.ietf.org/internet-drafts/draft-otani-ccard-00.txt Date: 1999-02-04 ------------------------------------------------------------------------ Capability Card Koji Otani INTERNET DRAFT Hiroyasu Sugano Madoka Mitsuoka Fujitsu Laboratories, Ltd. Expires: May 1999 18 Nov. 1998 Capability Card: An Attribute Certificate in XML Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes basic ideas and data components of 'Capability Card,' which is a kind of attribute certificates designed from the standpoint of a secure communication framework on the Internet. Similar to the SPKI certificates, a capability card can be used to grant a person particular access privileges to resources like WWW pages, IRC channels, and message boxes. In addition, it can carry a variety of descriptive information about the issuer, the resources, and the privileges specified in it. A capability card is written in XML, which is becoming a standard format rapidly for the internet data exchange. Consequently, users can handle various information in capability cards visually with an XML viewer. This is a fairly desirable feature for the existing internet services. In this document, following the motivation and the basic concepts, the elements of XML DTD of capability cards are described. Otani/Sugano/Mitsuoka [Page 1] INTERNET DRAFT Capability Card 18 Nov 1998 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. Otani/Sugano/Mitsuoka [Page 2] INTERNET DRAFT Capability Card 18 Nov 1998 Table of Contents 1. Introduction ......................................... 4 1.1. Backgrounds and Motivation ........................... 4 1.2. Capability Cards ..................................... 4 1.3. Glossary ............................................. 5 1.3.1. Capability ........................................... 5 1.3.2. Issuer ............................................... 5 1.3.3. Subject .............................................. 5 1.3.4. Holder ............................................... 5 1.3.5. Identity Authentication .............................. 5 1.3.6. Holder Authentication ................................ 6 1.3.7. Verifier ............................................. 6 2. Overview of Capability Cards ......................... 6 2.1. Attribute Certificates for Access Privileges ......... 6 2.2. Communication Instruments ............................ 6 2.3. XML .................................................. 7 2.4. Delegation and Its Control ........................... 7 2.5. Anonymous Subjects ................................... 7 2.6. Unsigned Cards ....................................... 8 3. Capability Card Data Elements ........................ 8 3.1. capability-card element .............................. 8 3.1.1. signature element .................................... 8 3.2. contents element ..................................... 9 3.3. descriptive information .............................. 9 3.3.1. short-text ........................................... 10 3.3.2. long-text ............................................ 10 3.3.3. image ................................................ 10 3.3.4. vcard-info ........................................... 10 3.4. capability element ................................... 10 3.4.1. target element ....................................... 11 3.4.2. verifier element ..................................... 12 3.4.3. access-right element ................................. 12 3.4.4. access-param element ................................. 12 3.4.5. description element .................................. 13 3.5. card-info element .................................... 13 3.6. issuer element ....................................... 13 3.6.1. user-info element .................................... 14 3.6.2. pk-certificate element ............................... 14 3.7. subject element ...................................... 15 3.7.1. user-info element .................................... 15 3.7.2. pk-certificate element ............................... 15 3.8. delegation element ................................... 16 4. Security considerations .............................. 17 5. Document Type Definition ............................. 18 6. Examples ............................................. 20 7. References ........................................... 25 8. Authors' Address ..................................... 25 Otani/Sugano/Mitsuoka [Page 3] INTERNET DRAFT Capability Card 18 Nov 1998 1. Introduction 1.1. Backgrounds and Motivation Secure authorization is one of the most important issues related to actual services on the Internet. Various internet services, includ- ing e-commerce, information sharing, and end-user communications, have different authorization requirements based on their own prob- lems; - Should I give 5% discount to this customer? - Should I allow this person to read that document? - Should I accept this chat request from that person? The SPKI group provides one solution to these problems based on pub- lic key technology[SPKI]. SPKI certificates are attribute certifi- cates which allow the designated key holders to have the specified access privileges. As SPKI certificates are designed to be generic, it seems to be applicable to a variety of services on the Internet. On the other hand, privacy protection and handling of undesirable messages have been matters of primary concerns of end-users for recent years. Such issues would become more serious when more con- venient messaging systems, like the instant messaging, prevail. We consider that the notion of attribute certificates will be applicable to solve the problems stated above. Suppose that a user could give another person the access privileges to herself in a certificate and the messaging server has incorporated a facility of access control based on such a certificate. Then, she would be able to preclude annoying messages from the parties without any certificates. More- over, she would be able to revoke the certificates she had issued to a party, which is no more trustworthy. 1.2. Capability Cards Based on the above motivation, we have been developing a secure com- munication framework using attribute certificates. We did not adopt the SPKI certificate for the following reasons. In a communication framework, users and service sites sometimes need extensible certifi- cates which allow to convey various descriptive information of several types, such as text, image data, or audio data. Some WWW com- merce sites may issue the customers a number of customer cards, which are certificates enclosing personalized information for each custo- mer. And, still using the same data format, they may not need to sign the data in some cases. Therefore, a data format suitable for such (possible) certificates should be fully extensible. "Capability Cards" are attribute certificates designed for such a new communication framework. A capability card contains some access Otani/Sugano/Mitsuoka [Page 4] INTERNET DRAFT Capability Card 18 Nov 1998 privileges (or capabilities) to the designated resources. Usually, it is digitally signed by an entity who has a responsibility for the specified resources, such as WWW pages and message boxes, and issued to another entity. The recipient can use it to access the issuer's WWW pages or to send messages to her. Moreover, a capability card can carry extra information about the issuer, the resources and the privileges, to help its current holder to know who the issuer is and what the holder can do with it. In this sense, a capability card can be used like a vCard[VCARD], an elec- tronic business card standard. Some capability cards can be transferred to others to delegate the specified privileges to them. This is sometimes desirable in intranets and some internet services like community sites. 1.3. Glossary In this document, some terms are used in the following meanings. 1.3.1. Capability The capability in a capability card is a privilege to access the specified resource. The capability is granted to the subject. 1.3.2. Issuer The issuer of a capability card is the entity who has specified its contents, and usually has signed it. 1.3.3. Subject The subject of a capability card is the entity who has a privilege to use the capability card. The subject is usually specified by the key, or other identity the relevant service accept. But it can be "anonymous" in some cases. 1.3.4. Holder The holder of a capability card is the entity who currently holds it. The holder can use the card if she/he is the same entity as the specified subject or the subject is anonymous. 1.3.5. Identity Authentication The identity authentication is the authentication which verifies the correspondence of an entity and an actual person. Otani/Sugano/Mitsuoka [Page 5] INTERNET DRAFT Capability Card 18 Nov 1998 1.3.6. Holder Authentication The identity authentication is the authentication which verifies that an entity is the subject of the card. 1.3.7. Verifier The verifier is the entity which verifies the validity of capability cards. It may be an application server or a separate server related with the application. 2. Overview of Capability Cards 2.1. Attribute Certificates for Access Privileges A capability card is a kind of attribute certificates designed for a new communication framework on the Internet. An entity issues a capability card to another entity, usually specifying the subjects, the resources, and the access privileges (or capabilities) to them, and the validity period, signing with her digital signature. A capa- bility card can convey multiple capabilities for the several resources. The issuer should have a responsibility for the specified resources in general. This responsibility relation will be verified at the time of the use. On the use of a capability card, the holder of the card firstly sends it to the verifier. At that time, the holder usually should be able to select one capability through a client's user interface. Then the verifier practices the holder authentication unless the subject is anonymous, and checks the validity of the use of the card. After the verification is completed successfully, the authorization information should be handed over to the resource by some means. The methods how the holder authentication is practiced and how the connection between the verifier and the application is established are not covered by this document. 2.2. Communication Instruments In addition to items necessary for the attribute certificate, a capa- bility card can convey some descriptive information about the items. For instance, it can include directory-style information about the issuer or the subject, similar to the entries listed in vCard elec- tronic business card standards. It can also have the explanations on what the resources are and what privileges the holder will have. The issuer can include various information on the specified items, like image data, short text description, and long text description. Otani/Sugano/Mitsuoka [Page 6] INTERNET DRAFT Capability Card 18 Nov 1998 One of the intended usage of such capability cards is for message cards with access privileges to some human-related resources, like users' home pages, service sites' reception pages, IRC channels, and contact points for instant messaging or IP telephony. This is a fairly desirable feature in internet services like commerce and com- munity sites. 2.3. XML Capability cards adopt XML (eXtensible Markup Language)[XML] as a syntactic framework of the data expression. Because XML is becoming rapidly recognized as a standard format for the internet data exchange, this adoption would make capability cards widely usable with various application softwares. For example, capability cards can be handled with an XML viewer to display images as the electronic business cards. Furthermore, XML is easily extensible to contain some extra data fields, thus this is convenient for individual service sites, which may sometimes need to put service-specific information into capabil- ity cards. 2.4. Delegation and Its Control One can transfer a capability card to other entities to delegate the capabilities to them. The unit of delegation is not a capability, but a capability card itself. Thus, in the case that a capability card contains multiple capabilities, all the capabilities are delegated at the same time. To delegate a capability card, one issues a new card including the old one. The new card is said to be "derived" from the old one. To control delegation of capability cards, the issuers can specify some parameters on delegation control; "depth," "propagate," and "width." "Depth" takes an integer which is the limit of the depth of delegation. "Propagate" takes a boolean, where false means the dele- gator loose all the privileges in the card and true means the delega- tor still possesses those privileges. "Width" takes an integer which is the limit of the width of delegation. The delegation control with these parameters may not be strictly performed. But the verifier SHOULD be able to follow the use of the delegated cards, and to detect an improper usage by verifying these parameters. 2.5. Anonymous Subjects Otani/Sugano/Mitsuoka [Page 7] INTERNET DRAFT Capability Card 18 Nov 1998 Although one usually issues a capability card specifying the subject, a capability card can be issued with the subject "anonymous" as well. When a capability card holder uses the card in general, the holder authentication must be fulfilled. But, in the case of anonymous sub- ject, the holder authentication is not necessary. Capability cards with anonymous subject may be useful to propagate the privileges to unknown masses. This is sometimes preferable when some sites advertise their services for unknown users including the privilege to access the WWW pages under some limitation. 2.6. Unsigned Cards In some cases, a capability card may not be digitally signed. If an issuer wants to issue a capability card only for the use of non security-critical services, or just for informative use, digital sig- nature may not be necessary. Thus, our framework allows a capability card to be issued without digital signatures. 3. Capability Card Data Elements As capability cards are written in XML (eXtensible Markup Language) [XML], the syntax is conformable to the XML syntax. XML elements for capability cards are described in XML DTD (Document type definition) here. We will adopt the XML namespace when the namespace specifica- tion is fixed in the near future. 3.1. capability-card element signature? ) > The "capability-card" element is the root element of the capability card. The "capability-card" element MUST contain a "contents" element and MAY contain a "signature" element. The "contents" element is described later. The "signature" element is defined as follows. 3.1.1. signature element > The content of the "signature" element is the issuer's digital signa- ture. This element has the "algorithm" attribute which specifies the name of the algorithm of digital signature. 3.2. contents element | capability* ), card-info, issuer, subject, delegation ) > The "contents" element is the body of capability cards. It consists of the elements listed above. 3.3. descriptive information Some of the elements described later can have descriptive information for the convenience of users and service sites. For the sake of facility of element definitions, the entity for descriptive informai- ton is defined here. long-text?, image?, vcard-info?, > The content of this element is an image which may be used as an icon. The image MUST be base64 encoded. The "format" attribute specifies the name of data format of the image, and the default is "jpeg." 3.3.4. vcard-info ) > > This is a vCard data in XML[vcard-xml]. The "href" attribute, whose value is URL, MAY be used to point to the vCard data. In that case, the content MAY be omitted. 3.4. capability element A capability card MAY contain zero or more "capability" elements. The Otani/Sugano/Mitsuoka [Page 10] INTERNET DRAFT Capability Card 18 Nov 1998 "capability" element specifies the resource and the privileges to be granted to the subject. verifier?, access-right, access-param?, description?, ) > not-before CDATA #IMPLIED not-after CDATA #IMPLIED > Meanings of the attributes are given as follows. (1) times-to-use attribute This attribute specifies the maximum number of times this capa- bility can be used. The value is an integer. If the value is less than or equal to 0, the capability can be used without limit. This attribute is optional. When this is omitted, the default value is 0. A verifier SHOULD be able to count the number of the use of each capability card and to check whether the number does not exceed the value of this attribute. (2) not-before attribute This attribute specifies the date/time when this capability becomes valid. The date/time MUST be specified in UTC time and the form is "YYYY-MM-DDTHH:MM:SSZ". This attribute is optional. If this is omitted, this capability is valid since its creation time. (3) not-after attribute This attribute specifies the date/time when this capability becomes invalid. The date/time MUST be specified in UTC time and the form is "YYYY-MM-DDTHH:MM:SSZ". This attribute is optional. If this is omitted, the validity of this capability does not expire. 3.4.1. target element Otani/Sugano/Mitsuoka [Page 11] INTERNET DRAFT Capability Card 18 Nov 1998 > This element contains information about the resource to which this capability may be applicable. The "uri" attribute is a URI of the target resource. The "uri" attribute MUST be specified. The content of this element is descriptive information about the target resource. 3.4.2. verifier element > This element contains information about the verifier that verifies this capability. The "uri" attribute is a URI of the verifier. The content of this element is descriptive information about the verif- ier. This element is optional. If this is omitted, the value of the target element MAY be used. 3.4.3. access-right element > This element specifies the access rights for the target resource to be granted to the subject. The content of this element is descriptive information on the access rights. Access rights are specified by a list of labels in the "label" attri- bute. A label is a name which represents a collection of access rights. The vocabulary for labels and access rights depends on the target resource. The mapping of a label to a collection of access rights is defined by an access control policy specified for the access control mechanism of the applications. 3.4.4. access-param element Otani/Sugano/Mitsuoka [Page 12] INTERNET DRAFT Capability Card 18 Nov 1998 This element specifies some parameters which are handed over to the application when the card is used to access the target resource. This element is optional. 3.4.5. description element This element contains descriptive information about this capability itself. 3.5. card-info element The "card-info" element contains information about the capability card itself. issued-date CDATA #REQUIRED > The content of this element is descriptive information about this card. Meanings of the attributes are given as follows. (1) card-id attribute This attribute is the card ID. The card ID SHOULD be globally unique. (2) issued-date attribute This attribute is the issued date. This MUST be specified as UTC time. The form is "YYYY-MM-DDTHH:MM:SSZ". 3.6. issuer element This element contains information about the issuer of the card. pk-certificate? ) > Otani/Sugano/Mitsuoka [Page 13] INTERNET DRAFT Capability Card 18 Nov 1998 A capability card MUST have information enough for a verifier to specify the issuer. In particular, a signed capability card MUST have information to get the issuer's public key. 3.6.1. user-info element > This element contains the issuer's information except the public key. The content of this element is descriptive information about the issuer. The "user-id" attribute specifies the issuer's ID by which the verif- ier can specify the issuer. If the card is not a derived one, it is usually the case that the issuer is a registered user at a service which provides the resource specified in the card. In this case, the registered ID is specified in this attribute. If this card is derive from any other card, a URI form can be used. 3.6.2. pk-certificate element > This element specifies the issuer's public key (X.509) certificate or the location to get the one. When the certificate itself is speci- fied, it is embedded in the content in a base64-encoded form. In the other case, the "name" attribute is used to designate the location where the issuer's certificate resides. A typical value of this attribute is an LDAP URL. If the "name" attribute is specified, the content SHOULD be empty. If the verifier can get the public key through the "user-id" attri- bute of the "user-info" element, this element may be omitted. For the purpose of the usage of capability cards, only a public key is needed rather than public key certificates. But, X.509 public key certificates is getting popular recently, thus we adopted them for the interoperability with PKIX. Our framework does not force the cer- tificate to be registered at a CA (Certificate Authority), however. Otani/Sugano/Mitsuoka [Page 14] INTERNET DRAFT Capability Card 18 Nov 1998 3.7. subject element This element contains information about the subject of the card. pk-certificate? ) > This element specifies the legal users of this capability card, but it can be anonymous when no restriction on its users is needed. For a capability card with the anonymous subject, any holder of it have the specified capabilities. Otherwise, this element MUST provide enough information to determine the subject. 3.7.1. user-info element > This element contains the subject's information other than the public key. The content of this element is descriptive information about the subject. The "user-id" attribute specifies the subject's user ID. If the sub- ject is a registered user at a service which provides the resource specified in the card, the registered user ID can be contained in this attribute. Otherwise, any ID of a URI form, except for "anonymous", can be used. The value "anonymous" is reserved for the case of the anonymous subject. 3.7.2. pk-certificate element > This element specifies the subject's public key (X.509) certificate or the location to get the one. When the certificate itself is specified, it is embedded in the content in a base64-encoded form. In the other case, the "name" attribute is used to designate the location where the subject's certificate resides. A typical value of Otani/Sugano/Mitsuoka [Page 15] INTERNET DRAFT Capability Card 18 Nov 1998 this attribute is an LDAP URL. If the "name" attribute is specified, the content SHOULD be empty. If the verifier can get the public key through the "user-id" attri- bute of the "user-info" element, this element may be omitted. For the purpose of the usage of capability cards, only a public key is needed rather than public key certificates. But, X.509 public key certificates is getting popular recently, thus we adopted them for the interoperability with PKIX. Our framework does not force the cer- tificate to be registered at a CA (Certificate Authority), however. 3.8. delegation element propagate (true | false) "false" width CDATA "0" > This element specifies the delegation parameters. Three attributes can be specified and they have the following meanings. (1) depth attribute This attribute is the maximum number of the depth of delegation. The value is an integer. If -1 is specified, the depth of dele- gation is unlimited. If 0 is specified, one cannot issue a new card derived from this card. The default value is 0. If this card is derived from another card, the value of this attribute SHALL be less than the value of the original card. (2) propagate attribute This attribute specifies whether or not the capabilities in this card can be propagated to other entities. In other words, it specifies the card to be self-reproducing or not. If this value is "true", the delegator can still have the capabilities after the delegation. If it is "false", one cannot use the capabili- ties any more after the delegation. The default value is "false". If the value of "depth" attribute is 0, this attribute MUST be ignored. If this card is derived from another card and the value of this attribute of the original one is "false", the Otani/Sugano/Mitsuoka [Page 16] INTERNET DRAFT Capability Card 18 Nov 1998 value of this attribute SHALL NOT be "true". Because the verifier cannot check the original card which has the false "propagate" value until the delegated one is verified, it is RECOMMENDED that the client program is to obey this attri- bute. (3) width attribute This attribute is the maximum number of the width of delegation tree, that is, the number of cards which can be directly derived from this card. The value is an integer. If 0 is specified, one cannot derive a new card from this. If -1 is specified, one can derive a new card without limit. This attribute is optional. If this is omitted, the default value is 0. If the value of "depth" attribute is 0 or the value of "propagate" attribute is "false", this attribute MUST be ignored. If this card is derived from another, the value of this attribute SHALL be less than or equal to the value of the original one. The verifier need not check this attribute literally. But, it is RECOMMENDED that the verifier counts the number of the use of the card directly derived from this one, and checks the number does not exceed this value. 4. Security considerations When one uses a capability card, the identity authentication is not mandatory. If it is needed, one can do it through a mechanism such as SSL(Secure Sockets layer)/TLS(Transport Layer Security). However, on the use of a capability card, the holder authentication is needed if the subject is not "anonymous." If the subject is specified by the public key, it is expected that the authentication is done through challenge-and-response using the key pair. When the issuer gives a capability card to the subject, the identity authentication may be needed. One can do it through a face-to-face method, SSL, or etc. Specifying these actual methods is beyond the purpose of this docu- ment. Since a capability card has neither the verifier's digital signature nor the service's digital signature, the issuer only assures that the card contains the specified capabilities. Otani/Sugano/Mitsuoka [Page 17] INTERNET DRAFT Capability Card 18 Nov 1998 Since descriptive information in a capability card is not assured by any authority, the information could not be used in a critical appli- cation. 5. Document Type Definition The XML DTD for capability cards is as follows. long-text?, image?, vcard-info?, > ) > > signature? ) > > | capability* ), card-info, issuer, subject, Otani/Sugano/Mitsuoka [Page 18] INTERNET DRAFT Capability Card 18 Nov 1998 delegation ) > verifier?, access-right, access-param?, description?, ) > not-before CDATA #IMPLIED not-after CDATA #IMPLIED > > > > issued-date CDATA #REQUIRED > pk-certificate? ) > Otani/Sugano/Mitsuoka [Page 19] INTERNET DRAFT Capability Card 18 Nov 1998 pk-certificate? ) > > > propagate (true | false) "false" width CDATA "0" > ] > 6. Examples [Example 1] This is a capability card which Sugano issued to Otani. The subject is Otani, and the privileges are that he can access to get Sugano's schedule and he can open a chat channel with Sugano by "project- partner"'s rights. These privileges are specified in "capability" elements. Since this card has a vCard element, a user agent can display Sugano's name, the address and the telephone number of his office. Using a capability-card enabled user agent, Otani can launch a chat client program by selecting the displayed menu item "Chat to Sugano," which is specified in the "description" of the "capability" element. Since the value of "depth" attribute of "delegation" element is 1, Otani can delegate the capabilities to others. Schedule Get Sugano's Schedule Sugano's Schedule Info chat page Connect Sugano's channel charset="ISO-2022-JP" Chat to Sugano SUGANO Hiroyasu SUGANO Hiroyasu Sugano +81-78-123-xxxx 64 Nishiwaki Ohkubo-cho Akashi Hyougo 674-8555 JP Otani/Sugano/Mitsuoka [Page 21] INTERNET DRAFT Capability Card 18 Nov 1998 Koji Otani -----BEGIN CERTIFICATE----- MIIDRjCCAwQCBDWTL6gwCwYHKoZIzjgEAwUAMIGIMQswCQYDVQQGEwJqcDEPMA0GA1UECBMG SHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFib3JhdG9yaWVz MScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzANBgNVBAMTBlN1 Z2FubzAeFw05ODA2MjYwNTIwNDBaFw05ODA5MjQwNTIwNDBaMIGIMQswCQYDVQQGEwJqcDEP MA0GA1UECBMGSHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFi b3JhdG9yaWVzMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzAN BgNVBAMTBlN1Z2FubzCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQD9f1OBHXUSKVLfSpwu7OTn 9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4AdNG/yZmC3a5lQpaSf n+gEexAiwk+7qdf+t8Yb+DtX58aophUPBPuD9tPFHsMCNVQTWhaRMvZ1864rYdcq7/IiAxmd 0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5lK+7+jrq gvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCjrh4r s6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GE AAKBgCzvLBspFFcdRq4qgdcRfG2WVgJCYd2WFVpRFi1EzgI8iwkmClvvDYF6508BRdK42UaZ 8VBzV93Glb/pQ2qp5xuLlCI9j6f6tZPPLJ37vQVdSMSpWYQJysq97QlU3mI6/AhyFWs702n5 5LsqskCRlm3Na8mk7nTy7m5ogxyRxDALMAsGByqGSM44BAMFAAMvADAsAhRKzI0Z4fBlQI8G hJa88XXkOugn6QIUcinz5Ay70iFwx+y0Ni93d94HMjI= -----END CERTIFICATE----- MCwCFAZ5hmanpq3YKHjLssKYrPNZhANRAhQfqMStMdWqvqipc02vpnbLsLWZoQ== [Example 2] This card is a derived card from the one in Example 1 issued by Otani. This card includes the original card in the "contents" ele- ment. The subject of this card is Mitsuoka. His public key certifi- cate is specified indirectly by the LDAP URL. The Verifier can get his certificate from the LDAP server "ldap.fujitsu.com" with the URL "ldap://ldap.fujitsu.com/o=Fujitsu%20Limited,c=JP??sub?(cn=Madoka%20Mitsuoka)". Mitsuoka is given the same capabilities as those granted to Otani. But since the value of "depth" attribute of "delegation" element is 0, Mitsuoka cannot delegate these capabilities to others. Otani/Sugano/Mitsuoka [Page 22] INTERNET DRAFT Capability Card 18 Nov 1998 Schedule Get Sugano's Schedule Sugano's Schedule Info chat page Connect Sugano's channel charset="ISO-2022-JP" Chat to Sugano Sugano Hiroyasu SUGANO Hiroyasu Sugano +81-78-123-xxxx 64 Nishiwaki Ohkubo-cho Otani/Sugano/Mitsuoka [Page 23] INTERNET DRAFT Capability Card 18 Nov 1998 Akashi Hyougo 674-8555 JP Koji Otani -----BEGIN CERTIFICATE----- MIIDRjCCAwQCBDWTL6gwCwYHKoZIzjgEAwUAMIGIMQswCQYDVQQGEwJqcDEPMA0GA1UECBMG SHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFib3JhdG9yaWVz MScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzANBgNVBAMTBlN1 Z2FubzAeFw05ODA2MjYwNTIwNDBaFw05ODA5MjQwNTIwNDBaMIGIMQswCQYDVQQGEwJqcDEP MA0GA1UECBMGSHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFi b3JhdG9yaWVzMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzAN dhjXBAMTBlN1Z2FubzCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQD9f1OBHXUSKVLfSpwu7OTn 9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4AdNG/yZmC3a5lQpaSf n+EexAiwk+7qdf+t8Yb+DtX58aophADUEPuD9tPFHsMCNVQTWhaRMvZ1864rYdcq7/IiAxmd 0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5lK+7+jrq gvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCjrh4r s6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GE AAKBgCzvLBspFFcdRq4qgdcRfG2WVgJCYd2WFVpRFi1EzgI8iwkmClvvDYF6508BRdK42UaZ 8VBzV93Glb/pQ2qp5xuLlCI9j6f6tZPPLJ37vQVdSMSpWYQJysq97QlU3mI6/AhyFWs702n5 5LsqskCRlm3Na8mk7nTy7m5ogxyRxDALMAsGByqGSM44BAMFAAMvADAsAhRKzI0Z4fBlQI8G hJa88XXkOugn6QIUcinz5Ay70iFwx+y0Ni93d94HMjI= -----END CERTIFICATE----- MCwCFAZ5hmanpq3YKHjLssKYrPNZhANRAhQfqMStMdWqvqipc02vpnbLsLWZoQ== Sugano Koji Otani Otani/Sugano/Mitsuoka [Page 24] INTERNET DRAFT Capability Card 18 Nov 1998 Madoka Mitsuoka MCwCFAZ5hmanpq3YKHjLxxKYrPUZhXNRAhQfqMStMdWqvqipc02vpnbLsLWZoQ== 7. References [SPKI] C. M. Ellison, et al., "SPKI Certificate Theory", draft-ietf- spki-cert-theory-03.txt, Work in Progress. [VCARD] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt, Sep. 1996. [MIME-VCARD] F. Dawson, and T. Howes, "VCard MIME Directory Profile", RFC2426, Sep. 1998. [XML] T. Bray, J. Paoli, and C.M. Sperberg-McQueen, "Extensible Markup Language(XML)1.0", W3C Recommendation, W3C, Feb. 1998. [VCARD-XML] F. Dawson, and P. Hoffman, "The vCard v3.0 XML DTD", draft-dawson-vcard-xml-dtd-01.txt, Work in Progress. 8. Authors' Address Koji Otani Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555, Japan sho@flab.fujitsu.co.jp Hiroyasu Sugano Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555, Japan suga@flab.fujitsu.co.jp Madoka Mitsuoka Otani/Sugano/Mitsuoka [Page 25] INTERNET DRAFT Capability Card 18 Nov 1998 Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555, Japan mitsuoka@flab.fujitsu.co.jp Otani/Sugano/Mitsuoka [Page 26]