Subject: Re: IP addresses & Taxes & Directories?

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 01 Apr 1999 12:11:02 -0500

This continues to have relatively little to do with any specifics
before the working group...

From:  Zahid Ahmed <[email-masked]>
Message-ID:  <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Date:  Tue, 23 Mar 1999 20:28:44 -0800

>I guess this discussion has gone from tax processing information
>that needs to be transmitted by the client to IP address resolution
>on the receiver side...
>
>Donald brought up the subject of secure DNSs so that when an
>OTP-aware server receives a request we can have some assurance that
>the request was coming from Proxy/Firewall/NAT location whose
>domain address is indeed "ibm.com" and not abc.com.
>
>To summarize, following informaion is minimally needed:
>
>1) Domain Information
>   High degree of assurance the network source of the request;

Why is this needed?  Do you believe tax authorities are going to
define tax obligations in terms of domain name?  I can't see, given
the nature of DNS, how that could be resonable.  Say you decided to
give some tax status to someone because of the apparent geographic
implications of their domain name.  First of all, there is no
guarantee it is correct.  For example, the host asylum.sf.ca.us, which
looks from its name like a machine in San Francisco, California, and
which it was at one time, has for many years been in Cambridge,
Massachusetts.  Even if you enforced a requirement where all city
level US registrars would only give out names to those who reside in
their city, there is no reasonable way to stop subdelegations.  Even
if asylum.sf.ca.us were in SanFrancisco, that says nothing about
example.asylum.sf.ca.us, which could be created by asylum, or
subexample.example.asylum.sf.ca.us which could be created by asylum or
by the example.asylum if it is delegated.

>2) Location Information
>   The geographical origin of the requestor immediate orgainziation; 
>   this is possibly available in the locality attribute of X.509 
>   certificate. However, what if the client uses the cert from a 
>   directory server from another state/country?
>
>3) Principal Information
>   need to know the identity of the requestor (as an individual,
>   possibly an (registered) organization - i.e., a group, or a
>   some other global/certified end entity Id);
>
>Now I know work is going on to specify secure DNS frameworks so
>that we can trust lookup results from DNSs. However, what about 

Note that all it does is make sure you can trust that the contents of
DNS are what those with authority over that part of the DNS have set
up, not that it is true or useful.  That is, that data you get from
the root zone ".", including who has authority over its subzones like
.com, is what those with authority over the generally accepted root
want; that the data you get from .com, including who has authority
over its subzones like example.com, is what those with delegated
authority over .com want; that the data you get from example.com,
including, say, the IP address to use for www.example.com, is what
those with delegated authority over example.com want; etc.

>geographical information and orgainzational information? Is that
>going to be available in secure DNS any time soon? From the

Secure DNS can secure any information that the DNS can store.  It
doesn't add to that, except that it adds security related stuff
(signatures, keys, etc.).  There is an LOC RR that can encode location
but it is not widely used (see RFC 1876, "A Means for Expressing
Location Information in the Domain Name System",
<http://www.ietf.org/rfc/rfc1876.txt>).

>RFC 2538 I have seen focus on AltSubjectName which can be used to 
>include DNS info. Don't know how you'll use that information alone 
>to find out about geographical origin of the request and more 
>specifically, the "Tax Domain" of the request.

RFC 2538 is just about how to store certificates in the DNS.
Certificates are signed entities and are normally verfied based on the
signature in the certificate.  You can store all kinds of info inside
certificates and if you trust the issuer of the certificate, maybe you
can trust that info.

>However, I think we need to consider simpler solutions:
>1) LDAP Directory Servers accessible over the extranet/internet
>   s.t. they store domain information which can be inquired over the 
>   internet once the request is received. SubjAltName would be
>   ideal for directories.
>
>2) Configure Proxy Servers and Firewalls to transparently 
>   attach common, static, organizational and geographical information 
>   about the client as part of the client cert:
>	- geographical location of the request sender;
>	- organization's Id (this need to reflect the global enterprise
>        ID, including any divisional info, e.g., IBM Global Services)

In my opinion, changing all the proxy servers and firewall in the world
is impractical.

>OTP is about payment protocols, but to solve this problem (the identity
>of the user, the orgins of the user, etc.) we also need an easily 
>deployable and cheap infrastructure...

IOTP is about trading.  Most any payment protocol can be tunneled
through IOTP.  The paymnet protocols generally provide their own
security.  The merchant mostly cares about getting paid.  They don't
don't generally need the identity of the customer.  And even if their
were a global tax inftrastrucutre, it is not clear that they need more
than the minimum information to figure out what tax rate to apply.

>Zahid Ahmed                     Commerce One, Inc.
>Commerce Security Architect
>email: [email-masked]
>v: (650)-623-2814
>fax: (650)-938-8055

Thanks,
Donald

>> -----Original Message-----
>> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
>> Sent: Tuesday, March 23, 1999 7:09 PM
>> To: [email-masked]
>> Subject: IP addresses (was Re OECD technical advisory group on
>> e-commerce and professional data assessment)
>> 
>> This doesn't have much to do with the IOTP protocol but I suppose it
>> might somehow effect future versions...\
>> 
>>  > Date:    Sat, 28 Feb 1998 07:30:33 MST
>>  > From:    John Messing <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > One of the pieces of data that a browser transmits to an 
>> inquiring server is
>>  > the static or dynamic IP address that it is currently 
>> using. A static IP
>>  > address is one that does not change. A dynamic IP address 
>> is provided on a
>>  > rotational basis by an ISP and usually changes with each 
>> connection. Most
>>  > consumers probably use ISP's and dynamic IP addresses.
>> 
>> Well, it is not particularly that a browser explicitly transits an IP
>> address when it does a query.  It is that the TCP connection process
>> that underlies any HTTP, FTP, SMTP/POP/IMAP (email), etc., transfer
>> necessarily involves each end learning the IP address of the other
>> end.  But, in all cases you may be getting the IP address of some
>> intermediate NAT (network address translation) box and/or firewall
>> and/or proxy/cache.
>> 
>>  > This address can be captured by the server and stored. The 
>> dyamic addresses,
>>  > for consumers, usually are modem of an ISP. The ISP's 
>> jurisdiction will not
>>  > necessarily be that of the user, but in most cases, it 
>> probably is. That
>>  > might be a place to begin for determining place of origin.
>> 
>> In fact, the address is almost always captured and written to a log
>> file, although the web server usually tries to translate the numeric
>> IP address into a domain name first.
>> 
>>  > The problem of using the P3 id no. is
>>  > 1. not everyone will have an Intel chip of that generation, and
>>  > 2. it will probably cause a ruckus among privacy groups to 
>> suggest it.
>> 
>> The IP address, while not particularly valuable, is certainly more
>> likely to be authentic than an id number that simply purports to be
>> a Pentium 3 serial number.  It seem to me a lot easier to fake that
>> than the IP addres.
>> 
>> 
>>  > Date:    Sun, 21 Mar 1999 13:16:48 EST
>>  > From:    "Milton M. Anderson" <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > Do IP addresses map to tax authority boundaries?
>> 
>> Not particularly.  Big blocks of IP address are frequently allocated
>> to specific registries or ISPs or companies but its common for
>> someone with a big block to sub-allocate them to activites in a wide
>> variety of locations.
>> 
>>  > How hard is it to install a hacker tool that will
>>  > spoof the PIII serial number?
>> 
>> From all I know, I think it would be pretty easy.
>> 
>>  > Milt
>> 
>> 
>>  > Date:    Sat, 28 Feb 1998 15:59:15 MST
>>  > From:    John Messing <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > I disagree that this thread is ridiculous. If the various 
>> participating
>>  > countries are willing to agree that the IP address of the 
>> ISP is the point
>>  > of sale because that is where the buyer logs on to the 
>> Internet, then it
>>  > might be a basis for a taxation convention between 
>> agreeing countries. The
>>  > ISP's all have corporate addresses in some jurisdiction or 
>> other. One need
>>  > only to consult internic to find out the jurisdiction 
>> where they are
>>  > located. If the seller is located in another jurisdiction 
>> from the buyer as
>>  > defined above, then intra country taxation issues can be 
>> negotiated and
>>  > presumably resolved.
>> 
>> Well, if you want to look up a numeric IP address, you need to ask
>> the regional IP registries, ARIN, RIPE, and/or APNIC, not the
>> Internic.  If you can back translate the IP addresses to domain
>> names and they are in a top level domain that the Internic handles
>> (.com, .net, .org, .edu), you can inquire there.  I don't know how
>> good the IP registry's records are but the Internic's have
>> essentially no quality control. As far as I can see, NSI will store
>> essentially any garbage you want in its records.  I suspect data
>> quality in the national domain name registries (.us, .ca, .uk, .jp,
>> etc.) varies a lot from country to country.
>> 
>> I would also note, that if you control an IP address, you can
>> generally put whatever domain name you want in its inverse lookup
>> location.  So if I control 10.123.61.30, I would normally also control
>> the data stored under 30.61.123.10.in-addr.arpa and could, for
>> exmaple, store a pointer to "whitehouse.gov" or "microsoft.com" or
>> "no.such.domain.name" there. However, you can get some assurance by,
>> after doing the inverse lookup, then doing the forward lookup and
>> seeing if you get back to the same numeric IP address you started out
>> with.  And all this will be improved when domain name system security
>> is deployued.  (Note: Network 10 is reserved for local use so IP
>> addresses starting with "10.", which I used in this example, are not
>> globally meaningful or unique and such networks have to be connected
>> to the global Internet through a NAT box to translate to a globally
>> unique address for routing.)
>> 
>> Thanks,
>> Donald
>> 
>> =====================================================================
>>  Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
>>  65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
>>  Carmel, NY 10512 USA
>> --------------------------------------------------------------
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: David Burdett <[email-masked]>
Date: Thu, 1 Apr 1999 18:58:56 +0100

The conclusion I'm drawing from this particular part of the thread is:
1. There will almost certainly be a need to somehow securely identify the
"tax location" (for want of a better phrase) of the parties involved so that
the correct taxes can be calculated.
2. Knowing how the "tax location" is defined *may* have some relevance on
IOTP since we will probably want to record it within the IOTP messages
somehow
3. Basing "tax location" on DNS, IP addresses or some other feature of
Internet topology does not look like a good idea.
4. We should let the tax experts work out what rules should apply for
determining "tax location" and calculating the apropriate tax to collect,
check that the approach is viable, and then work out how to best record it
in IOTP.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	01 April 1999 09:11
> To: 	Zahid Ahmed
> Cc: 	[email-masked]
> Subject: 	Re: IP addresses & Taxes & Directories? 
> 
> 
> Message-ID:
> <[email-masked]>