International Internet Governance in the Area of Infrastructure and Security

Contents: I. Introduction; II. Analysis of
initiatives; III. Initiatives’ Procedural Histories; IV. Commentaries;
References.

I. Introduction:

Two fundamental
functions of government are (1) to provide a certain level of infrastructure to enable people to conduct
daily affairs efficiently, and (2) to ensure the security of the land.
Historically, these two functions have always borne a close relationship
to each other, as strengthening the one helps to reinforce the other.

The Internet originally
grew out of a quest for security (that is, the aim of the U.S. Department of
Defense for technological supremacy over the Soviet Union).  In its short life to date, this technology
has become widely adopted and is now critical for the general infrastructure of
countries throughout the world.  With
this growing preeminence of the Internet for infrastructure, this technology is
no longer simply a means to a security end, but rather is also a vital part of
society needing protection.  Hence, as
in the traditional real world, infrastructure and security are intertwined for
cyberspace.

In infrastructure terms,
the Internet includes all the networks, computers, lines and cables of
communication, satellites, servers, backbones and computer languages (protocols
such as http, pop, smtp, ftp, tcp, ip, etc.) – all of which must be addressed
for the network of networks to function smoothly.

These same layers pose
challenges for cybersecurity.  As
processes of identification, authentication, validation, authorization and
confirmation at this stage are rather limited, enforcement agencies currently
do not see the face of the criminal, may not know what time or from what
location an attack is originating, and may not know what technologies are
involved in the crime.

While the Internet’s
advancement is presenting ever more complexities for infrastructure and
security, governments are increasingly institutionalizing international
approaches to legal and technological coordination to achieve a seamless,
secure network.  The international
organizations they are working through include: (i) Internet Society (“ISOC”);
(ii) Internet Architecture Board (“IAB”); (iii) Internet Engineering Task Force (“IETF”); (iv) Internet Research Task Force (“IRTF”); (v) Internet Corporation for Assigned Names and
Numbers (“ICANN”); (vi) International Telecommunication Union (ITU); and (vii)
World Wide Web Consortium (“W3C”)[1].

II. Analysis of initiatives:

Orientation of
International Collaborators:  Work is
Technical, Not Political

Who controls the
Internet? The answer is simple: generally speaking, nobody does.  However, the Internet is not totally “self
regulated”.

Background research for this paper
included a survey in which representatives of international organizations
working on infrastructure and security were all asked the same question:  Are
you or your international organization concerned about the legal aspects of
such an initiative?  In all cases
the answers were the same:  No.  As explained by them, the first stage is to
define an adequate standard for the technology to be deployed. The legal
analysis of such a standard is not carried out by the same groups that create
the standards.

The individuals involved in creating a
standard almost never require the assistance of a legal advisor. The reason, to
them, is simple: They are technicians and not lawyers. Their job is to design
tools that are useful.  Lawyers, on the
other hand, are seen as obstructive:  If
a scientist brings to a lawyer a sample of a new technology, it is almost
certain that the lawyer will identify so many problems that the technology will
never be launched.

So, too, this is the prevailing attitude
in the area of security:  The vantage
point for international organizations’ analysis of the security field is not
legal; rather, it is purely technical.

In other words, for the governance areas
of infrastructure and security, the people designing international solutions
are technical and task oriented.  Though
the political consequences of their decisions are great, these actors do not consider
it their responsibility to consider these wider implications of their
work.  Meanwhile, people who would take
these governance questions seriously tend to lack the technological expertise
to understand how choices affect the political power arrangement.

Structure of International
Cooperation:  Hierarchy of Technical
Bodies

The chart below offers
an indication of the Internet’s infrastructure and security management at the
international level.  It contains the
main organizations that are in charge of the maintenance and standardization of
technical parameters.[2]

While these organizations
have been actively promoting numerous initiatives, the ones described below
have been identified as priorities, based on: a) analysis of the content
of the relevant organizations’ Web sites; b) analysis of articles published on
Internet infrastructure; and (c) (the most important source) feedback from the
personnel from those international organizations by email or telephone.

2.1         Internet Protocol Version 6 (IPv6)

The Internet Protocol version 4
(IPv4), in use for the past 20 years, has the capacity to allocate Internet
address space for roughly 4 billion devices.
Because this address space is expected to be exhausted by 2008,
governments have endorsed initiatives to upgrade the system.

The Internet Engineering Steering
Group (IESG) chartered a working group for standardizing Internet Protocol
version 6 (IPv6) to accommodate the exponential growth of the Internet.[3]  Approximately 15 per cent of address space
under IPv6 will initially be allocated to already reserved addresses, while the
remaining 85 per cent will be reserved for future use.[4]

IPv6 Operations (v6ops) is a related
working group under the Internet Engineering Task Force (IETF).  This working group deals with the deployment
of the IPv6, since the IPv4 still running and a dual world is being formed
consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. According
to the specialists, the IPv6 “deployment must be properly handled to avoid the
division of the Internet into separate IPv4 and IPv6 networks while ensuring
global addressing and connectivity for all IPv4 and IPv6 nodes.”[5]

The IETF’s IPv6 Mobility (MIPv6) Working Group intends to determine the routing support in order
to permit an IPv6 host to continue using its “permanent” home address
as it moves around the Internet.[6]

2.2         Mobility

Every day more and more networks connect
to the Internet, and more people are becoming familiar with using different
electronic devices and tools.  With this
growth in mind, the IETF is working to create appropriate mechanisms to
stabilize and optimize the use of mobile networks.

IETF work on mobile networks[7] includes the following:- “Networks attached to people (Personal Area Networks or PANs): a cell-phone with one cellular interface and one Bluetooth interface together with a Bluetooth-enabled PDA constitute a very simple instance of a mobile network.  The cell-phone is the mobile router while the PDA is used for web browsing or runs a personal web server.- “Networks of sensors and computers deployed in vehicles: vehicles are more and more embedded with a number of processing units for safety and ease of driving reasons, as advocated by ITS (Intelligent Transportation Systems) applications.

“Access networks deployed in public
transportation (buses, trains, taxis, aircrafts): they provide Internet access
to IP devices carried by passengers

– (laptop, camera, mobile phone: host mobility within network mobility or PANs: network mobility within network mobility, i.e. nested mobility). – “Ad-hoc networks connected to the Internet via a [mobile router]: for instance students in a train that both need to set up an ad-hoc network among themselves and to get Internet connectivity through the [mobile router] connecting the train to the Internet.”

One group that is tangentially
working on the mobility issue is the Network Mobility Working Group (“NEMO”).[8]
NEMO is concerned with managing the mobility of an entire network, which
includes one or more mobile routers which connect such network to the Internet;
it also cooperates with the MIPv6 Working Group.
NEMO Working Group studies are very important due to the fact that each mobile
router must have a “home agent”. As indicted in the description of the Working
Group’s webpage, the current technology uses “bidirectional tunneling between
the [mobile router] and [home agent] to preserve session continuity while the
[mobile router] moves”[9].

The role of the Working Group is to
create standards for some basic support mechanisms based on the bidirectional
tunneling approach. In addition to that, NEMO Working Group is to “study the
possible approaches and issues with providing more optimal routing than can be
had with (potentially nested) tunneling. However, the [Working Group] is not
chartered to actually standardize a solution to such route optimization for
mobile networks at this point in time”.

2.3         Public Key X.509

Public Key Infrastructure (PKI) is a set
of hardware, software, people, policies and procedures needed to create,
manage, store, distribute, and revoke public key certificates (PKCs) based on
public-key cryptography.

In this regard, the PKI consists of five
components: “(i) the Certification Authorities that issue and revoke PKCs; (ii)
Organizational Registration Authorities that vouch for the binding between
public keys and certificate holder identities and other attributes; (iii)
Public Key Certificates holders are issued certificates and can sign digital
documents and decrypt documents using private keys; (iv) Clients that validate
digital signatures and their certification paths from a known public key of a
trusted Certification Authorities and that encrypt document using public key
from certificates of PKC holders; and (v) Repositories that store and make
available PKCs and Certificate Revocation Lists.”[10]

As evident from this list of components, PKI is not only a technology, but also a group of rules and procedures that together govern the concept of Public Key. These rules and procedures will also integrate with the technology used to deploy the Public Keys, which is the Public Key X.509.

The initial version of X.509 was
published in 1988, version 2 was published in 1993, and version 3 was proposed
in 1994 and considered for approval in 1995. Version

3 addresses some of the security
concerns and limited flexibility that were issues in versions 1 and 2.

As explained by
International Telecommunications Union (ITU)[11],
an X.509 certificate consists of the following fields:  version, serial number, signature algorithm
ID, issuer name, validity period, subject (user) name, subject public key
information, issuer unique identifier (version 2 and 3 only), subject unique
identifier (version 2 and 3 only), extensions (version 3 only), and signature
on the above fields.

This certificate is signed by the issuer to authenticate the binding between the subject (user’s) name and the user’s public key. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions, among others.[12]The IETF created the PKIX Working Group in 1995 to develop standards to support an X.509-based PKI. Nowadays, the PKIX Working Group not only profiles ITU PKI standards, but also develops new standards to the Internet use of X.509-based PKIs. In the PKIX Working Group[13], there are new items under discussion, including:(1)   production of requirements for delegated path discovery and path validation protocols (DPD/DPV) and subsequent production of request for comments for protocols that satisfy the requirements; (2)   development of a logotype extension for certificates;(3)   development of a proxy certificate extension and associated processing rules; and (4)   development of an informational document on PKI disaster recovery.Besides the IETF work on the X.509, the ITU has its own “ITU-T Recommendation X.509”, which specifies the authentication service for X.500 directories and the adopted X.509 certificate syntax.

According to the
information provided on the ITU webpage[14],
the “directory authentication in X.509 can be carried out using either
secret-key techniques or public-key techniques; the latter is based on
public-key certificates. The standard does not specify a particular
cryptographic algorithm, although an informative annex of the standard describes
the RSA algorithm.”

2.4         Global Routing Operations
(GROW)

The Global Routing Operations
Working Group was created to understand and develop new standards to the Border
Gateway Protocol (BGP), which is fundamental to the operation of the Internet.

With the increase of the operational
issues related to BGP, other concerns such as the routing table growth rates,
interaction of interior and exterior routing
protocols, dynamic properties of the routing system, and the effects of routing
policy on both the size and dynamic nature of the routing table, have arisen.
All of these issues have been discussed and analyzed by GROW.

GROW also advises various working
groups, including the IDR and RPSEC Working Groups, with respect to relevant
operational needs.

According the GROW’s Web site[15],
its goals comprise the following tasks:

1.
To provide a clear
definition of the problems facing Internet Routing Scaling today. This includes
routing table size and route processing load (former PTOMAINE goal).

2.
To collate measurements
of routing table scaling data and publish a reference list (former PTOMAINE
goal).

3.
To discuss and
document methods of filtering/aggregating prefix information and to discuss and
document what support from protocols or vendor knobs that might be helpful in
doing this. In addition, to suggest policy guidelines to RIRs, LIRs and/or ISPs
for allocations and aggregations,etc. that may be useful (former PTOMAINE
goal).

4.
To determine the long
and short term effects of filtering/aggregating prefixes to reduce router
resource consumption.

5.
To develop methods of
controlling policy information propagation in order to limit the need for
propagation of prefix sub-aggregates.

6.
To determine the
effects of using BGP as a signaling mechanism on the scalability of BGP (e.g.,.
draft-ietf-ppvpn-rfc2547bis-03.txt)

7.
To determine the
effects of interaction of new IGP techniques (e.g., ISIS-TE) on the stability
of BGP and in particular, what techniques are required to isolate the global
infrastructure from the any of the dynamic properties of such TE systems.

8.
To document
operational aspects of routing security and provide recommendations for
protocol specific work to RPSEC, IDR, and other Working Groups in the routing
area.

2.5         Routing Research Group

Routing on the Internet is one of the
most important issues for infrastructure and security. If we do not have
well-defined and organized routing, the entire system collapses. The Routing
Research Group was created to “explore routing problems that are important to
the development of the Internet but are not yet mature enough for engineering
work within the IETF”.[16]

For this reason, the RRG is to work with
the IESG Routing Area Director to ensure the free flow of information in both
directions and avoid duplication of work with the other IETF working groups
which are dealing with such issues.

The RRG Working Group is mandated to
“survey the state of the art in routing research and the needs of the user
community (ISPs, router vendors, etc.); based on these results and the
interests of the members, the group will choose a number of topics on which to
focus.”[17]

The survey also includes the: (i)
quality of service routing; (ii) scalable multicast routing, including
aggregation techniques; (iii) routing protocol stability; and (iv) extremely
dynamic routing.

There is no limited membership and
the RRG Working Group may hold open meetings from time to time to solicit input
from its members. As mentioned in its webpage, “once per year there will be a
review of the group’s activities held at an IETF meeting.”[18]

According to the IETF, this approach is
not a problem within the RRG since it is not producing “standards”. Thus, there
is no need to come to a single “answer” that satisfies everyone. Groups,
starting with different, possibly incompatible, premises may reach different,
incompatible conclusions. This is perfectly acceptable.

If a standard is to be developed, if a
“single answer” is required, then the IETF would be expected to create an
appropriate working group to develop that answer.

2.6         Network Management[19]

The Network Management Research Group
(NMRG) is a working group created to provide a forum for researchers to develop
and discuss new technologies and procedures for the Internet management. In
addition to that, another important duty of the NMRG is develop solutions for
problems not yet understood by the engineering work within the IETF.

As opposed to most of the other working
groups, the size of the NMRG is kept small (maximum of approximately 12
members). In order to avoid duplication of work among the various IETF’s groups
dealing with such issues, the IETF Operations and Management Area Directors are
included in the NMRG. The NMRG is not free for membership as many of the
working groups, such that any member is
chosen based on his or her expertise in the network management field and
only by means of indication by another member or invitation.[20]

2.7         E.164 – The ENUM[21]

The Internet is going to be everywhere.
Computers, palm tops, refrigerators, mobile phones, fixed phones etc. have already
some relation to the Internet. However, there are several numbers used to
access the Internet, to receive a phone call or to receive an e-mail.

An ambitious program has been launched
and it may cause a great revolution in the next years. This project is called
E-Numbering, or ENUM or E.164 and is held by the ITU[22]
and IAB.

The technical definition for E.164
is “ITU-T recommendation for international
telecommunication numbering, especially in ISDN, BISDN, and SMDS. 1) An
evolution of standard telephone numbers. 2.) Name of the field in an ATM
address that contains numbers in E.164 format.”[23]

This is not simple to understand. A
simple explanation can be that “E.164 addresses can be used in DNS by using ENUM. ENUM
allocates a specific zone, namely e164.arpa
for use with E.164 numbers. Any phone number, such as +1 555 42 42 can be
transformed into a hostname by reversing the numbers, separating them with dots
and adding the e164.arpa suffix, like so: 2.4.2.4.5.5.5.1.e164.arpa DNS can
then be used to look up internet addresses for services such as SIP VoIP[24]
telephony”.

The Internet Architecture Board (IAB)
and ITU-T Study Group 2 are discussing collaboration on the operational,
administration and delegation issues related to deployment of ENUM
protocol-based services. This requires extensive consultation with
administrators of resources derived from the international E.164 numbering plan
including national and integrated numbering plan administrators.

The
ITU-T Study Group 2[25]studies
the operational aspects of service provision, networks and performance Lead
Study Group on Service definition, Numbering, Routing and Global Mobility.

The main document that spells out
the ENUM and its relation to the DNS is the request for Comments 2916,
denominated “E.164 number and DNS”[26],
elaborated by the IETF Network Working Group.

Each country will be assigned an
E.164 country codes which will be associated to the Identification Code (IC)
assignments. The criteria and procedures to assign E.164 country codes are in
accordance with the principles contained in E.190 and the numbering plan
formats detailed in E.164.

According
to Ms. Dana M. Hirsh[27], the benefits of the
E.164 are to “allow
Internet-based users to make selections from a variety of services available
for communicating with other persons when callers know only a telephone number
or have access only to a telephone keypad. In addition, ENUM would enable users
to access Internet-based services and resources from Internet-aware telephones,
regular telephones connected to Internet gateways or proxy services, and other Internet-connected
devices where input is limited to numeric digits.”

“Users of ENUM would be able to specify their preferences
for receiving incoming communications, and they would have greater user control
over communications. For instance, a user would be able to indicate a preference
for voicemail messages over live calls during certain times of the day, or may
indicate a destination for call forwarding”[28].

2.8         Routing Protocol Security

The main purpose of the RPSEC is the
develop standards to ensure and adequate coverage of security for routing
protocol designers due to the lack of a common set of security requirements and
methods for routing protocols, which has resulted in a variety of security
mechanisms for individual routing protocols.

According to the information
provided[29], the “RPSEC
working group is charged with the following tasks:

(1)
Document threat
models for routing systems;

(2)
Document security
requirements for routing systems; and

(3)
Provide a common area
for discussion between security and routing experts on the topic of securing
the routing system.

2.9         IP Security Protocol

Another IETF working group
incorporated to deal with security is the IP Security Protocol Working Group
(IPSEC)[30].
The IPSEC is in charge of the development of mechanisms to protect client
protocols of IP, by creating a security protocol in the network layer to
provide cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.

The working group will also update
the existing key management protocol to clarify the specification and to
reflect implementation experience, new requirements, and protocol analysis of
the existing protocol.

2.10       ICANN Security Committee

The Committee on Security and
Stability will advise the ICANN community and Board on matters relating to the
security and integrity of the Internet’s naming and address allocation systems.
Reporting directly to the Board, the Committee is chartered to undertake the
following tasks[31]:

·
To develop a security
framework for Internet naming and address allocation services that defines the
key focus areas, and identifies where the responsibilities for each area lie.
The committee will focus on the operational considerations of critical naming
infrastructure;

·
To communicate on
security matters with the Internet technical community and the operators and
managers of critical DNS infrastructure services, to include the root name
server operator community, the top-level domain registries and registrars, the
operators of the reverse delegation trees such as in-addr.arpa and ip6.arpa,
and others as events and developments dictate. The Committee will gather and
articulate requirements to offer to those engaged in technical revision of the
protocols related to DNS and address allocation and those engaged in operations
planning;

·
To engage in ongoing
threat assessment and risk analysis of the Internet naming and address
allocation services to assess where the principal threats to stability and
security lie, and to advise the ICANN community accordingly. The Committee will
recommend any necessary audit activity to assess the current status of DNS and
address allocation security in relation to identified risks and threats;

·
To communicate with
those who have direct responsibility for Internet naming and address allocation
security matters (IETF, RSSAC, RIRs, name registries, etc.), to ensure that its
advice on security risks, issues, and priorities is properly synchronized with
existing standardization, deployment, operational, and coordination activities.
The Committee will monitor these activities and inform the ICANN community and
Board on their progress, as appropriate;

·
To report
periodically to the Board on its activity; and

·
To make policy
recommendations to the ICANN community and Board”.

2.11       W3C
Security

The W3C works on various subjects related to
security. They encompass computer system security, network security,
authentication services, message validation, personal privacy issues, and
cryptography.

Among all of the projects and
activities related to security, the W3C is,
according to its website[32],
involved in the:

(1) “development of several protocols
that relate to Web security”, such as the signed-XML proposed activity and the
HTTP/1.1 protocol (which includes a much improved scheme for authenticating the
identity of users known as Digest Authentication) and eCommerce (on the field
of secure payments, studied by the Electronic Commerce Interest Group). In
addition, the W3C also “produces software reference implementations that
demonstrate the use of security measures;

(2) joint IETF working group to
address XML Signatures (digital
signatures); and

(3) release of a Digital Signature
Initiative – the PICS Signed Labels 1.0 Recommendation, which permits that the
digital signatures be associated with PICS labels (a Web annotation system).”

The W3C maintains a webpage called “World Wide Web
Security FAQ” and provides an overview of Web security matters. Also, the
W3C regularly issues security alerts regarding the topic, which include
practical advice for avoiding unpleasant surprises.

III.         INITIATIVES’ PROCEDURAL
HISTORIES

3.1         Internet
Protocol Version 6

IPv6 Working Group

The IPv6 Working Group was created
in 1994. In December 1995, the IPv6 Working Group issued the Request for
Comments (“RFC”) No. 1884, entitled “IP Version 6 Addressing Architecture”[33].
This paper was to specify the addressing architecture of the IP Version 6
protocol [IPV6]. It contained the “IPv6 addressing model, text representations
of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and
multicast addresses, and an IPv6 nodes required addresses”.

In the same month and year, the IPv6
WG published another relevant document. The RCP No. 1887, named “An
Architecture for IPv6 Unicast Address Allocation”. This paper provided “an
architecture for allocating IPv6 unicast addresses in the Internet”. The
overall IPv6 addressing architecture was also defined therein.[34]

The same topic was proposed in July
1998 and April 2003 and other two papers called “IP Version 6 Addressing
Architecture” were released.

The next steps to be taken by the
IPv6 Working Group will be:

·
December 2003: (i)
Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461)
to be republished at Draft Standard; (ii) Submit Proxy RA to IESG for Proposed
Standard; and (iii) Submit update to IPv6 over PPP (RFC2472) to IESG for Draft
Standard.

·
January 2004:
Re-charter or close the Working Group.

There are many more documents
released by the IPv6 Working Group. The entire historical procedure of the IPv6
Working Group can be found on http://www.ietf.org/html.charters/ipv6-charter.html.

The “v6ops” Group

The v6ops
group was created in 2003 by the IETF. The only RFC issued was that No. 3574,
named “Transition Scenarios for 3GPP Networks”, which “describes different
scenarios in Third Generation Partnership Project (3GPP) defined packet
network, i.e., General Packet Radio Service (GPRS) that would need IP version 6
and IP version 4 transition.  The focus
of this document is on the scenarios where the User Equipment (UE) connects to
nodes in other networks, e.g., in the Internet.  GPRS network internal transition scenarios, i.e., between
different GPRS elements in the network, are out of scope. The purpose of the
document is to list the scenarios for further discussion and study.”[35]

Next steps are:

·
February 2004: (i)
Submit Cellular Deployment Solutions to IESG for BCP; and (ii) Submit
Transition Mechanisms to IESG for DS.

·
March 2004: (i)
Publish Enterprise Deployment Solutions as a WG I-D; and (ii) Submit IPv6
Neighbor Discovery On-Link Assumption to IESG for BCP.

·
April 2004: (i)
Submit Unmanaged Network Deployment Solutions to IESG for BCP; (ii) Submit Dual
Stack IPv6 on by Default to IESG for Informational; (iii) Submit ISP Deployment
Scenarios & Solutions to IESG for BCP; and (iv) Submit Application Aspects
of IPv6 Transition to IESG for Informational.

·
May 2004: Submit 6to4
Security Analysis to IESG for Informational.

·
August 2004: Submit
Enterprise Deployment Solutions to IESG for BCP.

For further information regarding
the historical procedures of this Working Group, please visit http://www.ietf.org/html.charters/v6ops-charter.html.

Mobile IPv6 (MIPv6)

Also created in 2003 by the IETF,
the MIPv6 Working Group has not issues any RFC. Its next goals are:

·
January 2004:
Bootstrapping problem statement to IESG.

·
February 2004: Submit
MIPv6 MIB to IESG.

·
March 2004: (i)
Alternate Route Optimization scheme to IESG; and (ii) Home agent reliability to
IESG.

·
August 2004: Bootstrapping
solution to IESG.

·
November 2004:
Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering
to IESG.

For further information regarding the
historical procedures of this Working Group, please visit http://www.ietf.org/html.charters/mip6-charter.html.

3.2         Mobility

Created in 2003 by the IETF, this
Working Group has not issues any RFC. The next steps are:

·
March 2004: Submit
the analysis of the solution space for route optimization.

·
June 2004: Shut down
or recharter the WG to solve the route optimization.

For further information regarding the
historical procedures of this Working Group, please visit  http://www.ietf.org/html.charters/nemo-charter.html.
3.3         Public
Key X.509

Created in 1995 by the IETF, the PKI
X.509 WG released several documents.

The PKI X.509 issued a paper on
March 1999, the Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework.

This paper spells out “A public-key
certificate (hereinafter ‘certificate’) binds a public-key value to a set of
information that identifies the entity (such as person, organization, account,
or site) associated with use of the corresponding private key (this entity is
known as the ‘subject’ of the certificate). A certificate is used by a
‘certificate user’ or ‘relying party’ that needs to use, and rely upon the
accuracy of, the public key distributed via that certificate (a certificate
user is typically an entity that is verifying a digital signature from the
certificate’s subject or an entity sending encrypted data to the subject). The
degree to which a certificate user can trust the binding embodied in a certificate
depends on several factors. These factors include the practices followed by the
certification authority in authenticating the subject; the [certification
authority’s] operating policy, procedures, and security controls; the subject’s
obligations (for example, in protecting the private key); and the stated
undertakings.”[36]

Recently, in November 2003,
essentially the same document was published, however it now had this focus:
“This document presents a framework to assist the writers of certificate policies
or certification practice statements for participants within public key
infrastructures, such as certification authorities, policy authorities, and
communities of interest that wish to rely on certificates.  In particular, the framework provides a comprehensive
list of topics that potentially (at the writer’s discretion) need to be covered
in a certificate policy or a certification practice statement.”[37]

Next steps are:

·
February 2004: Proxy
Certificate RFC.

·
March 2004: (i) SCVP
proposed Standard RFC; (ii) Progression of Qualified Certificates Profile RFC
to DRAFT Standard; (iii) Progression of Certificate & CRL Profile RFC to
DRAFT Standard; (iv) Progression of Time Stamp Protocols RFC to DRAFT Standard;
and (v) Progression of Logotype RFC to DRAFT Standard.

·
April 2004:
Progression of CRMF, CMP, and CMP Transport to DRAFT Standard.

·
June 2004: (i)
Progression of Proxy Certificate RFC to DRAFT Standard; (ii) Progression of
SCVP to Draft Standard; and (iii) Progression of Attribute Certificate Profile
RFC to DRAFT standard.

The entire historical
procedure can be found on http://www.ietf.org/html.charters/pkix-charter.html.

3.4         Global Routing Operations (GROW)

Created in 2003, this Working Group
issued a recent document in January 2004 called “BGP Communities for Data
Collection,” by which it explained that “BGP communities (RFC 1997) are used by
service providers for many purposes, including tagging of customer, peer, and
geographically originated routes.  Such
tagging is typically used to control the scope of redistribution of routes
within a provider’s network, and to its peers and customers. With the advent of
large scale BGP data collection (and associated research), it has become clear
that the information carried in such communities is essential for a deeper
understanding of the global routing system. This document defines standard
(outbound) communities and their encodings for export to BGP route collectors”.

There is no further information
regarding next steps on its website.[38]

3.5         Routing Research Group

There
is no information available regarding the historical procedure for this group.

3.6         Network Management

There
is no information available regarding the historical procedure for this group.

3.7         E.164 – The ENUM

      The only information available is that
the ITU-T Study Group 2 has a period of four years from 2001 to 2004.[39]

3.8         Routing
Protocol Security

Created
in 2003 by the IETF, the RPS Working Group has only one paper published.

The Generic Threats to Routing
Protocols of December 17, 2003, which states: “Routing protocols are subject to
attacks that can harm individual users or network operations as a whole. This
document provides a description and a summary of generic threats that affect
routing protocols in general. This work describes threats, including threat
sources and capabilities, threat actions, and threat consequences as well as a
breakdown of routing functions that might be separately attacked.”[40]

The next goal is in March 2004, when
IETF will evaluate progress, re-charter with new goals (see possible future
work above), or shut down.[41]

3.9         IP
Security Protocol

The next goal of the IP Security
Protocol Group is the Submit, in January 2004, a revised draft on IPsec Architecture
for consideration as Draft Standard.

For further information regarding its
historical procedure, please access http://www.ietf.org/html.charters/ipsec-charter.html.

3.10       ICANN
Security Committee

Recently launched by the Security
Committee the DNS Infrastructure Recommendation of the Security and Stability
Advisory Committee – SAC
005
Document 005 Version 1, on  November 1, 2003.

There is no further information
available on the next projects or steps.

3.11       W3C Security

There
is no further information regarding the next steps of this Working Group.

IV.          COMMENTARIES

As noted above, the agendas and
activities of international organizations dealing with infrastructure and
security are almost entirely technical.

For these reasons, it is not easy to
find legal commentary focusing on governance questions for the specific
initiatives presented in this paper. Commentaries found in this research are
therefore limited to the following topics: (i) IPv6; (ii) X.509; and (iii)
E.164.

4.1         IPv6
Commentaries

The big concern related to the
IPv6 is privacy and anonymity. In his paper “Translating Privacy Values with Technology,” Mr. Shawn C. Helms[42] points out his concerns about the IPv6
authentication capabilities, which is the most important change from IPv4 to IPv6.

According to Helms, “Currently, the structure of IPv4 allows users to create false return addresses
on data packets, thus making some communications virtually impossible to
trace.  IPv6, by contrast, marks each packet with an encryption ‘key’ that
cannot be altered or forged, thus securely identifying the packet’s origin. This authentication function can identify every
sender and receiver of information over the Internet, thus making it nearly
impossible for people to remain anonymous on the Internet.

“The current plans for IPv6 also allocate a permanent address to every device on the
Internet.  Currently, most IP addresses
are only temporarily allocated to Internet users. The new addresses of IPv6 ‘will be embedded in hardware,
and include information that can be traced back to individual network interface
cards.’ This will be like a permanent cookie that can never be disabled.  The U.S. government is supporting the
adoption of IPv6 technology in
order to protect public safety; IPv6
could, for example, help it catch Internet hackers. Such a system, however,
could certainly erode, if not eliminate, Internet anonymity.”

To Helms, “Americans are unknowingly giving up anonymity in exchange
for convenience, higher productivity, faster communication, better crime
prevention, and personalized information.
Such advancements are facilitated by the rapid development of
identification technologies.  The
proliferation of the Internet and these technologies is leading us toward a
world in which our every action is monitored and stored, thus creating the
Cyber-Panopticon.  This technological
trend toward persistent identification threatens a number of core values that
society has traditionally protected, including freedom of expression.”[43]

As noted earlier, the majority of the
concerns related to the IPv6 are privacy and anonymity issues. The following
articles deal with the same topic in almost the same manner:

(1)
52 Stan. L. Rev. 1315  Stanford Law Review  May, 2000, Symposium on Cyberspace and
Privacy: “A New Legal Paradigm?
Resolving Conflicting International Data Privacy Rules in Cyberspace,”
Joel R. Reidenberg.

(2)
52 Stan. L. Rev. 1461  Stanford Law
Review  May, 2000    Symposium
Cyberspace and Privacy: A New Legal Paradigm?   The Death of Privacy?
A. Michael Froomkin;

(3) 52 Stan. L. Rev.
1251  Stanford Law Review  May, 2000
Symposium  Cyberspace and
Privacy: A New Legal Paradigm?
Hardware-Based Id, Rights Management, and Trusted Systems, Jonathan
Weinberg;

(4) 9 Mich. Telecomm. & Tech. L. Rev.
395  Michigan Telecommunications and
Technology Law Review  Spring 2003    Comment
Regulating Speech Across Borders: Technology vs. Values,    Matthew Fagin;

(5)
3 Va. J.L. & Tech. 5  Virginia Journal
of Law & Technology  Spring
1998    An Analysis of Internet
Standardization,   Marcus Maher; and

(6)
79 Wash. U. L.B. 89  Washington
University Law Buarterly  Spring
2001    Articles   Fool US once Shame on You–fool US Twice
Shame on US: What We Can Learn From the Privatizations of the Internet Backbone
Network and the Domain Name System
Jay P. Kesan [FNa1]  Rajiv C.
Shah.

4.2         PKI
X.509 Commentaries

Trust in computer systems has always
been a problem. The PKI X.509 is a Public Key paradigm to prevent fraud and to
the data of someone (a person) or something (a specific computer). In the paper
called “Public Key Infrastructure and ‘Digital
Signature’

Legislation: Ten Public Policy Questions”, Mr. Brad Biddle[44]
asks:  “Should Legislation Endorse the X.509 Paradigm?”

Biddle identifies strong policy questions not yet
addressed:  If we trust in the X.509
infrastructure model, how can we trust in the authority certificate?  What liability is there for wrongdoing or
misuse of a public key?

As he notes: “When the Utah Act was enacted, it explicitly
endorsed the X.509
infrastructure model. Subsequent laws have dropped the explicit endorsement of X.509, but nonetheless remain true to
the X.509 paradigm. Under most
digital signature legislation, certificates serve to bind an individual’s
identity to a particular public key.
This binding is accomplished in the context of a rigid, hierarchical
[certification authority] infrastructure.

“This model has been criticized for two main reasons:
global [certification authority] hierarchies are almost certainly unworkable,
and identity certificates often provide too much information when frequently an
‘attribute’ or ‘authority’ certificate will do. Alternative certificate
formats, such as SDSI and SPKI, have emerged in response to these and other
perceived flaws with the X.509
model. However, it is not clear that these alternative certificate formats can
be accommodated under current digital signature legislation.”

Further
documentation may be found in the resources listed below:

(1)
2 No. 9 Elec. Banking L. & Com. Rep. 9
Electronic Banking Law and Commerce Report  March, 1998, Certification Infrastructure Needs for Electronic
Commerce and Personal Use, Carl M. Ellison;

(2)
38 Jurimetrics J. 359  Jurimetrics
Journal  Spring, 1998    Public Key Infrastructure Symposium   Public Key Infrastructure
Interoperation,  Michael S. Baum,
Warwick Ford ;

(3)
38 Jurimetrics J. 497  Jurimetrics
Journal  Spring, 1998    Public Key Infrastructure Symposium   EDI and Digital Signatures for Business to
Business Electronic Commerce, Juan Carlos Cruellas, Hoyt L. Kesterson II,
Manuel Medina, Montse Rubia;

(4)
38 Jurimetrics J. 243  Jurimetrics
Journal  Spring, 1998    Public Key Infrastructure Symposium   TUTORIAL.
Information Security Committee Section of Science and Technology
American Bar Association;

(5)
75 Or. L. Rev. 49  Oregon Law
Review  Spring 1996    Symposium: Innovation and the Information
Environment   The Essential Role of
Trusted Third Parties in Electronic Commerce,
A. Michael Froomkin

(6)
2 No. 2 Cyberspace Law. 7  Cyberspace
Lawyer  April, 1997    Public Key Infrastructure and
“Digital Signature” Legislation: Ten Public Policy Buestions,  Brad Biddle.

4.3         E.164/ENUM
Commentaries

An ITU official explained in a telephone conversation
that the E.164 has problems with respect to regulatory issues, since each country has sovereignty to decide the
deployment of telecommunication technologies within its territory. Similarly,
Ms. Dana M. Hirsh has noted[45]:

“The challenge
being faced by many countries as a result of the convergence of the worlds of
voice and data, is the decision over which government agency should oversee
ENUM. For instance, in the United States, the Federal Communications Commission
has regulatory authority over telephone numbers while the Commerce Department,
through the Internet Corporation for Assigned Names and Numbers (ICANN) manages
the Internet DNS.

“Another core issue in the debate regarding ENUM is
whether more than one company can operate and store the registry database to
which all ENUM queries are made.

“NeuStar Inc., the company that currently operates the
North American Numbering Plan (NANP), the master list of telephone area codes
and other telephone numbering resources in the United States and the rest of
North America, supports a system that would
be operated by a single, government- regulated authority. NeuStar currently is
operating the ENUM Public Trial on its ENUM.org web site. The ENUM Public Trial
is a DNS directory offered to providers of equipment and applications who wish
to test the ENUM technology.

“VeriSign Global
Registry Services, the registry operator for the .com Internet domain,
advocates the establishment of a competitive marketplace for the provision of
ENUM registration services, with participation by a variety of public
companies.”

The real question right now is who will hold the E.164
number list?

References:

Most
of the materials and information on which this research was based can be found
by accessing the Web sites listed below:

1. www.isoc.org

2. www.iab.org

3. www.ietf.org

4. www.irtf.org

5. www.icann.org

6. www.itu.org

7. www.w3c.org

8. http://livinginternet.com

9. http://www.faqs.org/rfcs/bcp/bcp9.html

10. ftp://ftp.isi.edu/in-notes/rfc1752.txt

11.
http://www.cse.iitk.ac.in/users/braman/courses/cs625-fall2003/lec-notes/lec-notes33-1.html

12. http://www.mobilenetworks.org/nemo/

13. http://www.x5.net/faqs/crypto/

14.http://business.cisco.com/glossary/tree.taf-asset_id=92874&word=92932&public_view=true&kbns=2&DefMode=.htm

15. http://www.nationmaster.com/encyclopedia/VoIP

Other
materials:

16. Internet Society Publication, July 2002, Lord
of the Numbers, Geoff Huston

17. 2 No. 9 Elec. Banking L.
& Com. Rep. 9,  Electronic Banking
Law and Commerce Report,  March, 1998,
Certification Infrastructure Needs for Electronic Commerce and Personal Use,
Carl M. Ellison.

18. 37 Idaho L. Rev. 353  Idaho Law Review  2001, The 2001 Symposium Edition, The Emperor’s New Clothes: The
Shocking Truth About Digital Signatures and Internet Commerce, Jane K. Winn.

19. Practising Law
Institute PLI Order No. B0-00N5 July, 2000 Telecom Deals: M&A, Regulatory
and Financing Issues 2000 NETWORK EFFECTS IN TELECOMMUNICATIONS MERGERS MCI
WORLDCOM MERGER: PROTECTING THE FUTURE OF THE INTERNET Constance K. Robinson Report Communications-

Electronics
Security Group (CESG), Issue 1.0.2, September 1997, Cloud Cover Confidentiality
Key Infrastructure Part 3: X.509 Certificate Profile.

20. Washington University Law Quarterly Spring 2001 Articles FOOL US ONCE
SHAME ON YOU–FOOL US TWICE SHAME ON US: WHAT WE CAN LEARN FROM THE
PRIVATIZATIONS OF THE INTERNET BACKBONE NETWORK AND THE DOMAIN NAME SYSTEM Jay
P. Kesan [FNa1] Rajiv C. Shah [FNaa1]

21. Journal of Small and Emerging Business Law Summer 1998 GATEKEEPERS AND
THE INTERNET: RETHINKING THE REGULATION OF SMALL BUSINESS CAPITAL FORMATION
Stephen J. Choi

22. Ohio Forms Legal and
Business Current Through July 2002 Supplement Contracts Chapter 11B. Internet
Transactions IV. Computer Use and Internet Policies E. Forms § 11B:44.20. —-
RULES AND REGULATIONS FOR NETWORK AND INTERNET ACCESS AND USE.

23. Lawyer’s PC August
15, 1999 STREETS & TRIPS 2000 The Computer Can Direct You From Here to
There Stephen Bird

24.
e-Commerce Law & Strategy November, 2002 Terminology Tips ENUM: MERGING PHONE, NET COMMUNICATIONS
Dana M. Hirsh [FNa1]

Boston
University Journal of Science and Technology Law

25. CRC Press, October
1996, Handbook of Applied Cryptography, Alfred J. Menezes,
Paul C. van
Oorschot and Scott A. Vanstone

26. 2 No. 9 Elec. Banking L.
& Com. Rep. 9  Electronic Banking
Law and Commerce Report  March, 1998,
Certification Infrastructure Needs for Electronic Commerce and Personal Use,
Carl M. Ellison;

27. 38 Jurimetrics J. 359  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   Public Key Infrastructure Interoperation,  Michael S. Baum, Warwick Ford ;

28. 38 Jurimetrics J. 497  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   EDI and Digital Signatures for Business to Business Electronic
Commerce, Juan Carlos Cruellas, Hoyt L. Kesterson II, Manuel Medina, Montse
Rubia;

29. 38 Jurimetrics J. 243  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   TUTORIAL.   Information
Security Committee Section of Science and Technology American Bar Association;

30. 75 Or. L. Rev. 49  Oregon Law Review  Spring 1996    Symposium:
Innovation and the Information Environment
The Essential Role of Trusted Third Parties in Electronic Commerce,  A. Michael Froomkin

31. 2 No. 2 Cyberspace Law.
7  Cyberspace Lawyer  April, 1997    Public Key Infrastructure and “Digital Signature”
Legislation: Ten Public Policy Buestions,
Brad Biddle.

32. 52 Stan. L. Rev. 1315  Stanford Law Review  May, 2000
Symposium  Cyberspace and
Privacy: A New Legal Paradigm?
Resolving Conflicting International Data Privacy Rules in Cyberspace,
Joel R. Reidenberg.

33. 52 Stan. L. Rev. 1461  Stanford Law Review  May, 2000
Symposium  Cyberspace and
Privacy: A New Legal Paradigm?   The
Death of Privacy?    A. Michael
Froomkin;

34. 52 Stan. L. Rev. 1251  Stanford Law Review  May, 2000
Symposium  Cyberspace and
Privacy: A New Legal Paradigm?
Hardware-Based Id, Rights Management, and Trusted Systems, Jonathan
Weinberg;

35. 9 Mich. Telecomm. & Tech. L. Rev. 395  Michigan Telecommunications and Technology
Law Review  Spring 2003    Comment
Regulating Speech Across Borders: Technology vs. Values,    Matthew Fagin;

36. 3 Va. J.L. & Tech.
5  Virginia Journal of Law &
Technology  Spring 1998    An Analysis of Internet Standardization,   Marcus Maher.

37. 2 No. 2 Cyberspace Law.
7  Cyberspace Lawyer,  April, 1997, Public Key Infrastructure and
“Digital Signature” Legislation: Ten Public Policy Questions, Brad
Biddle.

38. 38 Jurimetrics J. 497  Jurimetrics Journal,  Spring, 1998, Public Key Infrastructure
Symposium ,  EDI and Digital Signatures
for Business to Business Electronic Commerce,    Juan Carlos Cruellas, Hoyt L. Kesterson II, Manuel Medina,
Montse Rubia.

39. Data Security and Privacy Law: Combating Cyberthreats Kevin P. Cronin
and Ronald N. Weikers Current through the Fall 2003 Supplement Chapter 3.
Technical Security Measures Frank Mosuch [FNa1] Susan B. Hillson [FNaa1] § 3:1.
OVERVIEW