INTERNET-DRAFT ISO 7812 Numbers and the DNS
March 1998
Expires September 1998
ISO 7812 Card Numbers and the Domain Name System
--- ---- ---- ------- ---- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-eastlake-card-map-02.txt, is intended to
be become an Informational RFC concerning utilization of the Domain
Name System (DNS) in automated location of ISO 7812 financial
transaction identification card related facilities on the Internet.
Distribution of this document is unlimited. Comments should be sent
to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
Abstract
There are a variety of web pages, servers, and the like, which
holders of ISO 7812 based financial transaction identification cards
may need to locate on the Internet. For example, the SET protocol
being developed by VISA, MasterCard, and others assumes that a
cardholder can locate the appropriate certification authority to
obtain a cardholder certificate. This document proposes a method
using the DNS as an important element in locating financial
transaction card related facilities on the Internet by mapping ISO
7812 number prefixes into domain names within in the card.reg.int
domain.
Disclaimer
The methods proposed herein are not, at the time of the issuance of
this draft, endorsed by the credit card brands or associations.
Acknowledgment
Suggestions from the following persons, listed in alphabetic order,
have been incorporated in this document and are gratefully
acknowledged:
Doug Beattie, Electronic Commerce Consultants
Brian Carpenter, IBM
Roebert Elz, University of Melbourne
Tony Lewis, VISA International
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Disclaimer.................................................2
Acknowledgment.............................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 SET CA Location........................................4
1.2 ISO 7812 Details.......................................5
2. Inverse Number Mapping and Wildcards....................6
3. Card Domain Names Specified.............................7
3.1 Card Brand and Issuer Pointers.........................7
3.2 SET Certification Authority (CA) Pointers..............8
3.3 Financial Institutions Not On Line.....................9
3.4 BIN Ambiguity..........................................9
4. Security Considerations................................11
References................................................11
Author's Address..........................................12
Expiration and File Name..................................12
Appendix: Initial Brand Pointers..........................13
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
1. Introduction
Financial transaction cards such as credit cards and debit cards are
identified world wide by numbers issued in conjunction with ISO
standard 7812 [ISO 7812-1]. In general, the leading digits of such
card numbers, formally called the Issuer Identification Number (IIN),
indicate the issuing institution and the remainder of the number
identifies the individual card or account holder. The institution
prefix is sometimes referred to as the BIN (Bank Identification
Number), although it applies to more than banks, and the entire
number is somtimes known as the PAN (Primary Account Number), even
though these numbers are also used for secondary and other account
and identification numbers. Card numbers are generally issued in
connection with "brands" such as VISA, MasterCard, American Express,
JCB, Discover, Dinners Club, Air Travel Card, etc.
There has been no way, given a card number, to automatically find any
Internet site related to the card issuer, the card brand, or other
card facilities. In particular, the SET protocol [SET] defined by
VISA, MasterCard, and others, defines a means for cardholders, when
required, to obtain X.509 compliant certificates to attest to the
cardholder's authenticity but does not specify how to locate the
appropriate certification authority. Other protocol may require that
other facilities based on card number be reached over the Internet.
An means of automatically mapping such identification numbers into
domain names means that as soon as a number is know (due to user
account number entry or selection for a list of previous entered
PANs, for example), the ability would be present to easily attempt to
contact facilities on the Internet for that card. Thus web
browsers/wallets could, for example, provide "go to card brand", "get
a SET certificate", "go to issuing bank", etc., buttons whenever an
IS 7812 identification number is known.
1.1 SET CA Location
The most urgent potential need today is to locate SET Certification
Authorities (CAs).
In some cases, cardholders will be given URLs in mailings from the
card issuer or on their card itself. However, there will be other
cases, such as older cards that have not had a CA URL added or a card
for which the URL has changed due to bank mergers or splits or DNS
changes. Furthermore, in certification authority interaction, the
user will be required to supply their full account number in any case
and the requirement that they also manually enter a URL means
additional effort and opportunity for error. Note also that ISO 7812
account numbers have a built in check digit to catch most
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
typographical errors while URLs do not.
The system described in this draft permits SET Certification
Authority location without these problems.
1.2 ISO 7812 Details
Formally, ISO 7812 identification card numbers are divided as
follows:
1 2-6 7-v last
+-----+-------------------+-----------+-------------+
| MII | issuer identifier | | |
+-----+-------------------+ account # | check digit |
| issuer identification # | | |
+-------------------------+-----------+-------------+
| ISO 7812 identification number |
+---------------------------------------------------+
MII = Major Industry Identifier as follows
0 - for ISO/TC 68 and other industry assignments
1 - airlines
2 - airlines and other industry assignments
3 - travel and entertainment
4/5 - banking/financial
6 - merchandizing and banking
7 - petroleum
8 - telecommunications and other industry assignments
9 - for national assignment
If the number starts with 9, the next three digits are the numeric
country code as defined in ISO 3166 and the remainder of the number
is as defined by that national standards body for that country.
Account numbers are variable length up to a maximum of 12 digits.
The check digit is calculated modulo 10 by the Luhn formula over all
the preceeding digits as specified in ISO 7812.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
2. Inverse Number Mapping and Wildcards
When numbers are allocated in lexically hierarchical blocks so that a
prefix or suffix of digits is a meaningful division, the DNS wildcard
feature can be used to provide a convenient delgation and lookup
mechanism when the numbers and prefixes/suffixes are variable length.
In this regard, it is important to remember that more specific names
override less specific ones for DNS wildcards.
Domain names start with the most significant label on the right and
go to less significant labels as you go left while in card numbers
the leading or left most digits are the most significant while the
trailing or right most digits are less significant. Thus, the digits
must be reversed to match the card number and DNS naming systems and
the digits must be interspersed with dots to provide hierarchical
division into DNS domains.
Note that the transformed, reversed card number need not be exposed
to users but could be generated internally by software in an
automatic fashion.
For example, currently the American Express card brand is the only
one using numbers starting with 37. However, this is not a guarantee
for all time and it could be that at some point BIN numbers starting
with 37 would be assigned to a different brand. If you are looking
up facility "z" for card number 37012345678 (not a valid American
Express number), you could do a retrieval with a name like
3.2.1.0.7.3.z.card.reg.int. A wild card RR with the name
*.7.3.z.card.reg.int would match this and would appear in the
response with its name expanded to the specific name asked for, but
only if there were no more specific name. If there were a
3.2.1.0.7.3.z.card.reg.int specific name, for instance, it would
always be chosen in preference to the *.7.3.xz wildcard in this case
because it is a more exact match. On the other hand, if a retrieval
were done for 7.7.7.7.7.3.z.card.reg.int, it would get the more
general *.7.3.z.card.reg.int wild card since it does not match the
more exact wildcard. (The situation is generally somewhat more
complex than indicted here because additional intermediate length
wildcards may be needed. See the Appendix for a more complete
example zone.)
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
3. Card Domain Names Specified
Subdomains are defined within the card.reg.int domain for access to
the brand, the SET certification authority, and the card issuer.
Additional subdomains may be added if additional facilities
differently indexed by the card number require access.
To find a facility, you need to (1) get the BIN, (2) reverse the
order of these digits, and (3) put a dot between each digit and add
the appropriate facility suffix as shown below. The financial
transaction identification number MUST be truncated to avoid
revealing the full number in the DNS queries.
Sections 3.1 and 3.2 give further details on the facilities
available, section 3.3 discusses what to do about banks which are not
on line, and section 3.4 discusses what to do if the BIN is too
specific or not specific enough.
None of the facility pointers obtained via these means need be
exclusive and these financial identification card related Internet
facilities may have other names and URLs that will also work. These
facilities are intended to supplement, not necesarily replace, the
direct communication of domain names and URLs from financial
institutions to their customers.
3.1 Card Brand and Issuer Pointers
The card brand and issuer home pages can be located by creating the
numeric portion as above and appending ".brand.card.reg.int" or
".issuer.card.reg.int" respectively. A CNAME RR will be stored at
that name pointing to the actual domain name for the home page. A
CNAME is chosen, rather than having specific "A" RRs pointing to
host(s), "MX" RRs pointing to mail servers, etc., to minimize the
update load on the card.reg.int domain. Changes in the serving host,
mail servers, etc., need only be made under the facility's domain
name, which the CNAME points to, rather than also under card.reg.int.
For example, the brand for the card 551204..., a MasterCard card, can
be found by browsing at 4.0.2.1.5.5.brand.card.reg.int. and the
issuer for the card 471922..., a VISA card, can be found by browsing
at 2.2.9.1.7.4.issuer.reg.card.int. These domain names can be
automatically generated from a card number and need not be exposed to
ordinary users.
The Appendix shows possible initial content of the brand.card.reg.int
domain. There are relatively few brands and they are allocated to
moderately compact blocks of numbers with relatively few exceptions
not belonging to the block brand. So there will probably be under
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
2,000 entries in the brand.card.reg.int subdomain.
Since there are only a few tens of thousands of banks and other
issuers of significance in the world for financial transaction cards,
there should be well under 200,000 entries in the issuer.card.reg.int
subdomain.
Although at this time very large blocks of numbers are generally
allocated to brands (for example almost all card numbers starting
with 5 and 4 are MasterCard and Visa cards, respectively), some
numbers within these large blocks may be carved out by more specific
entries for other brands.
3.2 SET Certification Authority (CA) Pointers
A very high level description of the cardholder certificate issuance
procedure in SET [SET] is for a cardholderCInitRequest initialization
message to be sent to the CA, an initialization response received,
then a registrationFormRequest is sent to the CA and a either
registration form returned which the user fills in or a referral to
another CA is returned. The completed registration form is submitted
in a certificateRequest message to which there is a response which
can include the certificate or indicate it will be issued later or
indicate a failure.
The above sequence can occur over a variety of transports [SET-EIG]
including TCP and HTTP. TCP would be to the SET well known port 257,
unless some other port was mutually agreed on, but cardholder to CA
communication is normally expected to be HTTP. In HTTP, the sequence
is usually preceded by a kick-off message from the CA which is of
MIME type Application/SET-Registration-Initiation which activates a
SET wallet.
There are three pointers provided in connection with CAs, one for the
CA general web page for browsing, one derived URL that can be hit to
produce the SET certificate issuance kick-off message, and a derived
URL that can be used to post the initial cardholderCInitRequest if a
kick-off cycle is not needed.
The certification authority home page can be found as described in
3.1 above for brands and issuers, except that the suffix is
.set-ca.card.reg.int.
A CNAME will also be used in this subdomain. At this time it is not
clear in how many cases a certification authority will correspond to
a single BIN, to a brand, to blocks of BINs, or even to part of a BIN
(see section 3.4). Note that the wild card mechanism can easily
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
accommodate arrangements such as a default certification authority
for a brand with specific CAs for some BINs within that brand.
To determine the URLs to hit for the SET certificate issuance wake up
message [SET-EIG], take the CA domain name as above, prefix it with
"http://", and suffix it with "/SET-Registration-Initiation". For
some purposes, the wake up message may not be necessary. In that
case, the cardholderCInitRequest SET message [SET] can be POSTed
directly to a similar URL but with the suffix of
/cardholderCInitRequest.
Suffix to Domain Name Action
/SET-Registration-Initiation Certificate Request Wakeup
/cardholderCInitRequest SET msg to start cert. req.
Note that no explicit DNS retrieval is necessary. In initiating a
cardholder certificate application for card number 8765432109, you
mechanically transform the number into a URL and go. In this case
that would be, to start with a kick-off,
<http://3.4.5.6.7.8.set-ca.card.int/SET-Registration-Initiation>.
3.3 Financial Institutions Not On Line
Some numbers are allocated to institutions that do not have a network
presence. In some of those cases, a wildcard will provide an
appropriate pointer, say to a brand supplied bank lookup page that
provides telephone number and address to contact the bank. However,
in cases where the next higher level wildcard would provide
inappropriate pointers for such institutions, it will be necessary in
some cases to add entries for such numbers which are CNAMEed to
"not-on-line.card.reg.int" which will not exist. Thus an appropriate
error message will be generated.
3.4 BIN Ambiguity
For the facilities under card.reg.int defined thus far in this
document, the BIN is defined as the first six digits of the account
number. In many cases an issuer or certification authority is
defined by fewer digits. This is no problem as a wild card can be
used to match all extensions of this shorter prefix. However, cases
where six digits are insufficient need special handling as describe
below. In the future, there might be facilities added under
card.reg.int that are accessed via classes of ISO 7812 numbers not
subject to this six digit security limitation.
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
If multiple institutions have decided to share a BIN, there are
several ways it can be handled. For the issuer web page either (1)
the banks sharing the BIN can run a common web page with links to
their individual pages on it or (2) if they are all the same brand,
the brand can run such a multi-issuer referral page at the BIN or, in
some cases, at a higher level wildcard or (3) in the unlikely event
that they are different brands, the card.reg.int maintenance agency
can run a page providing access to the different sub-BIN issuers. A
multiple issuer home page could just have names, icons, and links to
the separate institutions or more complex indexing if it covered many
banks. While this problem in not expected to arise for the
brand.card.reg.int subdomain, similar solutions apply if it does.
In the cases where a URL is derived to access SET certification
authority facilities, and the BIN is ambiguous, a different
implementation is used. In particular, instead of a human looking at
a web page, we may have an application trying to get a cardholder
certificate. However, when the registration process reaches the
point of sending the CA a registration form request, that request is
accompanied (securely) by the full account number. The registration
form response can have, instead of a registration form, a referral to
a different URL. Thus, the certification authority could be simply a
secure referral program that uses as much of the identification
number as it wishes, quite possibly more than the fist six digits, to
determine where to forward the cardholder application.
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
4. Security Considerations
This document concerns a means to map ISO 7812 financial
identification numbers into the Domain Name System (DNS) so that card
related facilities on the Internet can be automatically located. The
security of the resulting pointers is dependent on the integrity of
the card.reg.int maintenance agency and the security of the DNS,
including the use of security extensions [RFC 2065]. However, note
that when used in connection with SET certificate issuance, the SET
security mechanisms provide strong protection against spoofing or
compromise of sensitive information even if the DNS were subverted.
For currently existing types of ISO 7812 numbers care should be taken
in making DNS queries that an entire sensitive identification number
is NOT used. Since DNS queries are not encrypted, this would expose
the card number within the Internet. No more than the initial six
digits should be used.
References
[ISO 3166] - Codes for the representation of names of countries.
[ISO 7812-1] - Identification card - Identification of Issuers.
[RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987
[RFC 1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
Kaufman, January 1997.
[SET] - Secure Electronic Transaction (SET) Specification, Version
1.0, May 31, 1997, available from <http://www.setco.org>.
Book 1: Business Description
Book 2: Programmer's Guide
Book 3: Formal Protocol Definition
[SET-EIG] - External Interface Guide to SET Secure Electronic
Transaction, September 24, 1997, available from
<http://www.setco.org>.
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 978 371 7148
EMail: dee@cybercash.com
Expiration and File Name
This draft expires September 1998.
Its file name is draft-eastlake-card-map-02.txt.
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT ISO 7812 Numbers and the DNS
Appendix: Initial Brand Pointers
This table shows the initial brand name pointers that might be
installed in the BRAND.card.reg.int domain.
Initial Name CNAME
*.1.brand.card.reg.int www.air-travel-card.com
*.3.brand.card.reg.int default.card.reg.int
*.0.3.brand.card.reg.int www.dinersclub.com
*.6.0.3.brand.card.reg.int www.dinersclub.com
*.9.6.0.3.brand.card.reg.int www.jcb.co.jp
*.8.0.3.brand.card.reg.int www.dinersclub.com
*.8.8.0.3.brand.card.reg.int www.jcb.co.jp
*.1.3.brand.card.reg.int www.jcb.co.jp
*.3.3.brand.card.reg.int www.americanexpress.com
*.3.3.3.brand.card.reg.int www.americanexpress.com
*.7.3.3.3.brand.card.reg.int www.jcb.co.jp
*.5.3.brand.card.reg.int www.jcb.co.jp
*.6.3.brand.card.reg.int www.dinersclub.com
*.7.3.brand.card.reg.int www.americanexpress.com
*.8.3.brand.card.reg.int www.dinersclub.com
*.4.brand.card.reg.int www.visa.com
*.5.brand.card.reg.int www.mastercard.com
*.6.brand.card.reg.int default.card.reg.int
*.0.6.brand.card.reg.int default.card.reg.int
*.1.0.6.brand.card.reg.int default.card.reg.int
*.1.1.0.6.brand.card.reg.int www.novus.com
(MasterCard actually only has numbers starting with 51, 52, 53, 54,
55, and 56 but until some other brand actually has cards issued with
a number starting with a 5, there is no reason to go to any more
detail in the wildcard. JCB is actually 3528, not all of 35* but the
same reasoning applies.)
Donald E. Eastlake 3rd [Page 13]