EP1169835A2 - Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge - Google Patents

Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge

Info

Publication number
EP1169835A2
EP1169835A2 EP00923157A EP00923157A EP1169835A2 EP 1169835 A2 EP1169835 A2 EP 1169835A2 EP 00923157 A EP00923157 A EP 00923157A EP 00923157 A EP00923157 A EP 00923157A EP 1169835 A2 EP1169835 A2 EP 1169835A2
Authority
EP
European Patent Office
Prior art keywords
proxy
server
trustworthy
code
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00923157A
Other languages
German (de)
English (en)
Inventor
Robert W. Scheifler
James H. Waldo
Peter C. Jones
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of EP1169835A2 publication Critical patent/EP1169835A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Definitions

  • the present invention relates generally to data processing systems and, more particularly, to using downloaded code to provide secure communication between a client and a remote service in a distributed system.
  • BACKGROUND OF THE INVENTION Today's distributed systems can be made up of various components, including both hardware and software. Nodes in distributed systems typically communicate via a network such as the Internet. One means of communication between programs in a distributed system is downloading code from one program to another. For example, a client (e.g., a program running on a node in a distributed system) can access a service running on a remote node by downloading code from the remote service.
  • a “service” refers to a resource, data, or functionality that can be accessed by a user, program, device, or another service and that can be computational, storage related, communication related, or related to providing access to another user.
  • Examples of services include devices, such as printers, displays, and disks; software, such as applications or utilities; information, such as databases and files; and users of the system.
  • a "class” provides a template for the creation of "objects” (which represent items or instances manipulated by the system) having characteristics of that class. Thus, a class defines the type of an object. Methods associated with a class are generally invoked on the objects of the same class or subclass.
  • the JavaTM programming language is described in The JavaTM Language Specification by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996, which is incorporated herein by reference.
  • a system consistent with the present invention enables a user in a distributed system to determine whether downloaded code is trustworthy before using the downloaded code to communicate with others in the distributed system. For example, if a client downloads code from a service, the client can verify that both the service and the downloaded code are trustworthy before using the code to communicate with the service. "Trustworthy" code is code that the client knows will enforce the client's security constraints (e.g., mutual authentication, confidentiality, and integrity) when communicating with the service,.
  • code is downloaded from a server, and a set of constraints to implement secure communication with the server is determined. Secure code is then used to verify that the downloaded code will enforce the set of constraints when the downloaded code is used to communicate with the server.
  • a first proxy containing code for communication purposes is downloaded, and a second proxy containing code for communication purposes is obtained from the first proxy.
  • a trustworthiness verification routine is used to determine whether the second proxy is trustworthy, and when it has been determined that the second proxy is trustworthy, the second proxy is used to determine whether a server is trustworthy.
  • a trustworthiness verification routine is requested from the server by using the second proxy and this verification routine is then used to identify the trustworthiness of the first proxy.
  • the first proxy is used to invoke a method on the server.
  • Fig. 1 depicts a distributed system suitable for practicing methods and systems consistent with the present invention
  • Fig. 2 depicts the logical interaction between a client and a service once the client has downloaded a proxy
  • Fig. 3 is a high-level flow chart of an exemplary method for establishing trust in a downloaded proxy in accordance with methods and systems consistent with the present invention.
  • Figs. 4A and 4B are flow charts depicting the steps of the verifyProxyTrust method for establishing trust in a downloaded proxy.
  • a distributed system suitable for practicing methods and systems consistent with the present invention can be implemented using the JiniTM architecture.
  • a JiniTM system is built around one or more lookup services that list the services available in the distributed system. When a service joins the network, it uses a process called discovery to locate the lookup service or services for the network. The service registers by passing a proxy object to each lookup service.
  • the proxy object is a JavaTM object implementing the interfaces of the corresponding service.
  • a client e.g., a program
  • the client interacts with the lookup service and downloads the proxy to facilitate use of the service.
  • the JiniTM architecture is described in more detail in Arnold, The JiniTM Specification. Addison-Wesley (1999).
  • a system consistent with the present invention enables a program in a distributed system to determine whether downloaded code is trustworthy before using the downloaded code to communicate with other programs or services in the distributed system. For example, if a client downloads code from a service, the client can verify that both the service and the downloaded code are trustworthy before using the code to communicate with the service. "Trustworthy" code is code the client knows will enforce the client's security constraints in communicating with the service.
  • constraints can include, for example, integrity, anonymity, mutual authentication, delegation, and confidentiality.
  • the "integrity” constraint ensures that messages will not be tampered with in transit
  • the "anonymity” constraint permits the identity of the client to stay unknown to the service
  • “mutual authentication” refers to the client and service verifying their identities to one another.
  • the “delegation” constraint allows the service to make calls to other computers using the client's identity
  • the "confidentiality” constraint ensures that messages are private, e.g., by using encryption.
  • the constraints attached to a proxy are included in the serialized version of the proxy.
  • an object such as a proxy, is converted into a serialized version of itself before being passed.
  • the serialized object contains enough information to enable the recipient to identify and verify the JavaTM class from which the contents of the object were saved and to restore the contents to a new instance.
  • Object serialization is explained in the JavaTM Object Serialization Specification, available at http://web2.java.sun.eom/products//jdk/1.3/docs/guide/serialization/spec/serialTO C.doc.html, which is incorporated herein by reference.
  • FIG. 1 depicts a distributed system 100 suitable for practicing methods and systems consistent with the present invention.
  • Distributed system 100 includes a plurality of computers 102, 104, and 106, communicating via a network 108.
  • Network 108 may be a local area network, wide area network, or the Internet.
  • Computer 102 includes a memory 110, a secondary storage device 112, a central processing unit (CPU) 114, an input device 116, and a video display 118.
  • Memory 110 includes a client program 142 and JavaTM runtime system 120, which includes a JavaTM remote method invocation (RMI) system
  • RMI JavaTM remote method invocation
  • Computers 104 and 106 may be similarly configured, with computer 104 including memory 124, secondary storage device 126, and CPU 128, and computer 106 including memory 130, secondary storage device 132, and CPU 134.
  • Memory 124 of computer 104 includes a service 136
  • memory 130 of computer 106 includes a lookup service 138 that defines the services available in one part of distributed system 100.
  • Lookup service 138 contains one proxy object for each service within that part of distributed system 100. Each "proxy object" corresponds to a service in the distributed system and implements interfaces corresponding to methods available from a service.
  • proxy object 140 would implement database interfaces such as "find” or "sort.”
  • client 142 asks lookup service 138 for a proxy to the database service.
  • lookup service 138 returns proxy object 140 corresponding to database service 136 to the client.
  • Lookup services are explained in greater detail in U.S. Patent Application No.09/044, 931 , entitled “Dynamic Lookup Service in a Distributed System,” which is incorporated herein by reference.
  • FIG. 2 depicts the logical interaction between client program 142 and service 136 once the client has downloaded proxy 140.
  • Proxy 140 implements one or more interfaces 202 corresponding to the methods 204 offered by service 136.
  • Client 142 invokes methods on proxy 140.
  • Proxy 140 processes method invocations, communicates with service 136 to execute the requests of client
  • proxy 140 The protocol between proxy 140 and service 136 is not set by the JiniTM system; instead, it is determined by the service and its proxy. This enables a client to communicate with a service it may have never seen before without knowing or caring how the service works. In this way, the JiniTM architecture relies on downloaded code to provide services in a dynamic and flexible way. Once a client downloads a proxy object, the client invokes methods on the proxy to communicate with the remote service. However, the proxy may be implemented using code that the client does not trust. Before sharing any critical data with the service, the client needs to establish trust in the proxy, the service, or both.
  • Figure 3 is a high-level flow chart of an exemplary method for establishing trust in a downloaded proxy in accordance with methods and systems consistent with the present invention.
  • the exemplary method enables a client to use code that can be verified locally to communicate with a remote service. Using the locally-verified code, the client verifies the remote service and then asks the service whether the service trusts the downloaded proxy. If the client has verified the service and the service trusts the proxy, then the client has established transitive trust in the proxy.
  • the exemplary method begins when the client downloads the proxy, P1 , from a lookup service (step 302).
  • the client then asks P1 for a second proxy to the service, P2, by invoking a method on P1 corresponding to a method on the service (step 304).
  • the client examines the code in P2 to verify that P2 uses only trusted code (step 306). If the client verifies P2 (step 307), then the client uses P2 to authenticate the service by invoking a method on P2 (step 308). If the service is authenticated (step 309), the client then uses P2 to ask the service if the service trusts P1's code, by invoking a method on P2 to obtain a proxy verifier from the service, and then passing P1 to the proxy verifier (step 310). If the service trusts P1 (step 311), then the client can trust P1 (step 312). In this manner, the client uses local, trusted code to establish trust in a downloaded proxy.
  • RMI Security Subsystem defines classes and interfaces that ensure secure communication between remote objects.
  • One class provided by the RMI Security Subsystem is the Security class, which includes the verifyProxyTrust method.
  • the verifyProxyTrust method establishes trust in downloaded code and is defined as follows: public static void verifyProxyTrust (
  • the verifyProxyTrust method in RMI system 122 is called by client 142 once the client downloads proxy 140, before the client makes any other use of the proxy. As described below, the method will establish trust in the proxy by confirming that the proxy will correctly implement the RemoteSecurity interface, part of the Security class.
  • the service can include the RemoteSecurity interface, which provides methods enabling a client to attach security constraints to the proxy or to query the service to determine the service's security constraints.
  • the RemoteSecurity interface is defined as follows: public interface RemoteSecurity ⁇ RemoteSecurity setClientConstraints (
  • SecurityConstraints constraints include SecurityConstraints getClientConstraints(); SecurityConstraints getServerConstraints (String name, Class[] parameterTypes); throws NoSuchMethodException, RemoteException; boolean equalslgnoreConstraints(Object obj);
  • the setClientConstraints method allows a client to make a copy of the proxy with a new set of constraints selected by the client.
  • the getClientConstraints method returns the current client constraints attached to the proxy.
  • the getServerConstraints method returns the server's constraints for a particular remote method implemented by the proxy.
  • the constraints can include, for example, integrity, anonymity, mutual authentication, delegation, and confidentiality.
  • Figures 4A and 4B are flow charts showing the steps of the verifyProxyTrust method.
  • the call has as its parameters the proxy and the client's security constraints.
  • the verifyProxyTrust method first determines whether the downloaded proxy is a secure RMI stub.
  • a stub is one example of a proxy, created by the RMI System, that uses the RMI protocol to communicate with a service.
  • a secure RMI stub is an instance of a class generated by the Java. lang. reflect. Proxy class provided by the JavaTM programming language.
  • the methods of the Proxy Class include Proxy.isProxyClass, which returns true if it is passed a proxy class that was generated by the Proxy Class, Proxy. getlnvocationHandler, which returns the invocation handler associated with the proxy instance passed as its argument, and Proxy. getProxyClass, which generates a Java. lang. Class object for a proxy given a class loader and an array of interfaces.
  • the verifyProxyTrust method calls the Proxy.isProxyClass method, passing the class of the proxy as a parameter, to determine whether the proxy is an instance of a trusted generated Proxy class (step 402). As described above, the Proxy.isProxyClass method will return true if and only if the specified class was dynamically generated to be a trusted proxy class.
  • the Proxy.isProxyClass method If the Proxy.isProxyClass method returns true, the proxy is an instance of a trusted class, and the verifyProxyTrust method tests the invocation handler of the proxy to determine if it is an instance of a trusted class (step 404).
  • Each secure RMI stub has an invocation handler used to invoke methods on the proxy.
  • the verifyProxyTrust method calls the local Proxy.getlnvocationHandler method, passing the proxy as a parameter.
  • the getlnvocationHandler method returns the invocation handler of the proxy, and the verifyProxyTrust method then calls the local instanceof operator to determine whether the proxy's invocation handler is an instance of a local trusted class, SecurelnvocationHandler.
  • the local trusted class SecurelnvocationHandler is specified in the Security class in RMI 122.
  • the corresponding local calls made by verifyProxyTrust are:
  • Proxy.isProxyClass(proxy.getClass()) handler Proxy. getlnvocationHandler(proxy) handler instanceof SecurelnvocationHandler As explained above, these methods are provided by the Java. lang. reflect.Proxy class of the JavaTM programming language.
  • each socket factory instance contained in the invocation handler is checked (step 406).
  • a socket is an end-point to a communication path between two processes in a network.
  • a socket factory is an object that implements a method to create a new socket. Socket factories are described in more detail at http://java.sun.eom/products/jdk/1.3/docs/api/java/net/SocketlmplFactory.html.
  • the class of each socket factory instance in the proxy is compared to a local list of trusted socket factory classes.
  • the verifyProxyTrust method uses a local configuration database to obtain TrustVerifier.
  • TrustVerifiers are provided as part of the JavaTM RMI Security Subsystem in RMI system 122, and are defined as follows: public interface TrustVerifier ⁇ boolean trustedConstraintClass(Class c); boolean trustedPrincipalClass(Class c); boolean trustedClientSocketFactoryClass(Class c); boolean trustedProxy(Object proxy, SecurityConstraints constraints) throws RemoteException; ⁇
  • the local configuration database contains a list of TrustVerifier instances that implement methods for testing the security of a given proxy or class.
  • the trustedClientSocketFactoryClass method will return true if the given class is a trusted socket factory class defined in RMI 122.
  • the verifyProxyTrust method calls the trustedClientSocketFactoryClass method of each TrustVerifier instance, passing the socket factory class as a parameter. If at least one trustedClientSocketFactoryClass method returns true for each socket factory, the proxy is a secure RMI stub (step 408). If the proxy is not an instance of a trusted Proxy class, or if the invocation handler is not secure, or if the socket factories are not trusted, then the proxy is not a secure RMI stub (step 410).
  • An RMI stub can be either unicast or activatable, depending on how it was exported by the service it represents.
  • a unicast stub works until its service goes down.
  • an activatable stub will still work after its service goes down because an activatable stub is capable of restarting the service, if necessary.
  • Each activatable stub contains an Activation ID consisting of information needed for activating the stub's corresponding object, e.g., a remote reference to the object's activator and a unique identifier for the object.
  • the verifyProxyTrust method takes additional steps to determine whether the proxy is a secure RMI activatable stub.
  • the verifyProxyTrust method obtains an activator verifier by making a remote call, using the proxy's invocation handler, to the remote service's getActivatorVerifier method, passing the client constraints as parameters (step 414).
  • the getActivatorVerifier method is provided in the RMI system of an activatable service to enable a client to verify a proxy's Activation ID.
  • the call to getActivatorVerifier returns an activator verifier plus optional codebase and signer information.
  • the activator verifier is an object received from the service containing code that implements the verifyActivatorTrust method, explained below.
  • the codebase information is the location from which the code, i.e., the activator verifier, should have been downloaded, e.g. a uniform resource locator (URL).
  • the signer information identifies the creator or creators of the code, i.e., the activator verifier. Because the verifier could have been downloaded, the verifyProxyTrust method checks that the activator verifier can be trusted using the codebase and signer information (step 416). If the service returned codebase information, the verifyProxyTrust method calls a local RMICIassLoader.getClassAnnotation method, which returns the location where the activator verifier code was obtained.
  • the verifyProxyTrust method compares that location to the codebase information from the service. If they are different, the activator verifier is not used because its code is not trusted. If one or more signers is specified by the service, the verifyProxyTrust method obtains the signers of the verifier by calling the local Class. getSigners method and compares them to the signers specified by the service. If they are different, the activator verifier is not used because its code is not trusted.
  • the verifyProxyTrust method uses local methods to confirm the activator verifier code, which may have been downloaded and therefore could be corrupted. If the service did not specify either codebase or signer information, the verifyProxyTrust method confirms that the activator verifier was not downloaded, i.e., that the activator verifier is local, and therefore trusted. To do this, the verifyProxyTrust method compares the classloader of the verifier's class to the context classloader of the current thread or an ancestor of the context classloader. If they are the same, then the activator verifier was not downloaded, and can be trusted.
  • the verifyProxyTrust method ensures that the activator verifier can be trusted, as described above, it extracts the Activation ID from the stub and calls the verifyActivatorTrust method of the verifier, passing the Activation ID as a parameter (step 418).
  • the verifyActivatorTrust method will return normally if the service trusts the activation ID passed to it (step 420). If any of these calls do not return normally, i.e., throws an exception, then the proxy is not a secure RMI activatable stub (step 422), otherwise trust is established (step 424). Trusting a proxy other than a secure RMI stub If the proxy is not a secure RMI stub, the client can still establish trust in the proxy. If the proxy's class has a method with the signature
  • proxy's verifyProxyTrust method is called recursively to get down to a secure RMI stub.
  • the original verifyProxyTrust i.e., the method called by the client program, then makes a call to proxy2's getProxyVerifier method.
  • the remote service returns a proxy verifier plus optional codebase and signer information
  • the verifyProxyTrust method checks the proxy verifier code using the codebase and/or signer information in the same way as described above with respect to the activator verifier. Once the verifyProxyTrust method ensures that the proxy verifier can be trusted, it makes a local call to the verifyProxyTrust method of the verifier, passing the proxy as a parameter. If any of these calls do not return normally, i.e., throws an exception, then the proxy is not trusted.
  • the proxy is not a secure RMI stub and does not have the getSecureProxy method
  • an ordered list of TrustVerifier instances is obtained from the local configuration database, as described above.
  • the verifyProxyTrust method calls the trustedProxy method of each TrustVerifier instance, with the proxy and client constraints as parameters.
  • the trustedProxy method returns true if the given proxy is known to be trusted to correctly implement the RemoteSecurity interface, and false otherwise. If any method returns true, then trust is established. If none returns true, trust is not established.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un procédé permettant à un programme, dans un système réparti, de déterminer si un code téléchargé est fiable avant utilisation de ce code téléchargé pour communiquer avec d'autres programmes ou services, dans le système réparti. Un client, qui télécharge un code mandataire à partir d'un service, peut vérifier si à la fois le service et le code téléchargé sont fiables avant d'utiliser le code pour communiquer avec le service. Le code «fiable» est celui connu par le client pour répondre aux exigences de sécurité du client dans la communication avec le service, par exemple, l'authentification mutuelle, la confidentialité et l'intégrité.
EP00923157A 1999-04-08 2000-04-07 Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge Withdrawn EP1169835A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12840699P 1999-04-08 1999-04-08
US128406P 1999-04-08
PCT/US2000/009249 WO2000062142A2 (fr) 1999-04-08 2000-04-07 Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge

Publications (1)

Publication Number Publication Date
EP1169835A2 true EP1169835A2 (fr) 2002-01-09

Family

ID=22435232

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00923157A Withdrawn EP1169835A2 (fr) 1999-04-08 2000-04-07 Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge

Country Status (5)

Country Link
EP (1) EP1169835A2 (fr)
JP (1) JP2002541578A (fr)
AU (1) AU4332800A (fr)
CA (1) CA2366670A1 (fr)
WO (1) WO2000062142A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7565533B2 (en) 2002-11-05 2009-07-21 Sun Microsystems, Inc. Systems and methods for providing object integrity and dynamic permission grants
US11082491B2 (en) 2016-10-07 2021-08-03 Microsoft Technology Licensing, Llc Propagating origin information for applications during application installation

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167520A (en) * 1996-11-08 2000-12-26 Finjan Software, Inc. System and method for protecting a client during runtime from hostile downloadables

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0062142A3 *

Also Published As

Publication number Publication date
CA2366670A1 (fr) 2000-10-19
WO2000062142A3 (fr) 2001-01-04
AU4332800A (en) 2000-11-14
JP2002541578A (ja) 2002-12-03
WO2000062142A2 (fr) 2000-10-19

Similar Documents

Publication Publication Date Title
US6138238A (en) Stack-based access control using code and executor identifiers
US6691113B1 (en) Persistent data storage for client computer software programs
US7716719B2 (en) System and method for providing application services with controlled access into privileged processes
US6070239A (en) System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources
US6167522A (en) Method and apparatus for providing security for servers executing application programs received via a network
KR19980079252A (ko) 서브릿을 처리하기 위한 장치 및 방법
US6901518B1 (en) Method and system for establishing trust in downloaded proxy code
US20240311464A1 (en) Registration of dynamically created packaged applications
US7155737B1 (en) Integrating user specified extensions into an information access system
US7363487B2 (en) Method and system for dynamic client authentication in support of JAAS programming model
US20050066198A1 (en) Controlling cooperation between objects in a distributed software environment
EP1169835A2 (fr) Procede et systeme d'etablissement de la fiabilite dans un code mandataire telecharge
Anderson Java™ access control mechanisms
EP1057110A2 (fr) Exigences de securite dans des systemes a empilement
Ismail Evaluation of authentication mechanisms for mobile agents on top of Java
Ongg An architectural comparison of distributed object technologies
US7366896B1 (en) Systems and methods for limiting access to potentially dangerous code
Ram et al. A framework for dynamic client-driven customization
Wheeler et al. Java Security
Gousios et al. Distributed component architectures security issues
Klemm Security Mechanisms in Distributed Component Models
Herbert et al. Mobile Java objects
Bhakthavatsalam Secure and controlled access to server resources in a mobile agent framework
Jusoh Integrating stand-alone Web-based spatial information systems into integrated spatial information system
DREUILLE et al. Analysis of Java security for the specific application of secure Remote Management over the Internet.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20011101

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SUN MICROSYSTEMS, INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20031031

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IE