idnits 2.17.1 draft-eastlake-card-map-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-eastlake-card-map-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-card-map-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-card-map-02.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-card-map-02.txt,', but the file name used is 'draft-eastlake-card-map-02' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 234: '...ification number MUST be truncated to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 166 has weird spacing: '...irlines and o...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1998) is 9348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISO 3166' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC 1034' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 420, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 7812-1' ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET-EIG' Summary: 12 errors (**), 1 flaw (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT ISO 7812 Numbers and the DNS 2 Expires September 1998 4 ISO 7812 Card Numbers and the Domain Name System 5 --- ---- ---- ------- ---- --- ------ ---- ------ 7 Donald E. Eastlake 3rd 9 Status of This Document 11 This draft, file name draft-eastlake-card-map-02.txt, is intended to 12 be become an Informational RFC concerning utilization of the Domain 13 Name System (DNS) in automated location of ISO 7812 financial 14 transaction identification card related facilities on the Internet. 15 Distribution of this document is unlimited. Comments should be sent 16 to the author. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 32 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 33 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 35 Abstract 37 There are a variety of web pages, servers, and the like, which 38 holders of ISO 7812 based financial transaction identification cards 39 may need to locate on the Internet. For example, the SET protocol 40 being developed by VISA, MasterCard, and others assumes that a 41 cardholder can locate the appropriate certification authority to 42 obtain a cardholder certificate. This document proposes a method 43 using the DNS as an important element in locating financial 44 transaction card related facilities on the Internet by mapping ISO 45 7812 number prefixes into domain names within in the card.reg.int 46 domain. 48 Disclaimer 50 The methods proposed herein are not, at the time of the issuance of 51 this draft, endorsed by the credit card brands or associations. 53 Acknowledgment 55 Suggestions from the following persons, listed in alphabetic order, 56 have been incorporated in this document and are gratefully 57 acknowledged: 59 Doug Beattie, Electronic Commerce Consultants 61 Brian Carpenter, IBM 63 Roebert Elz, University of Melbourne 65 Tony Lewis, VISA International 67 Table of Contents 69 Status of This Document....................................1 71 Abstract...................................................2 72 Disclaimer.................................................2 73 Acknowledgment.............................................2 75 Table of Contents..........................................3 77 1. Introduction............................................4 78 1.1 SET CA Location........................................4 79 1.2 ISO 7812 Details.......................................5 81 2. Inverse Number Mapping and Wildcards....................6 83 3. Card Domain Names Specified.............................7 84 3.1 Card Brand and Issuer Pointers.........................7 85 3.2 SET Certification Authority (CA) Pointers..............8 86 3.3 Financial Institutions Not On Line.....................9 87 3.4 BIN Ambiguity..........................................9 89 4. Security Considerations................................11 90 References................................................11 92 Author's Address..........................................12 93 Expiration and File Name..................................12 95 Appendix: Initial Brand Pointers..........................13 97 1. Introduction 99 Financial transaction cards such as credit cards and debit cards are 100 identified world wide by numbers issued in conjunction with ISO 101 standard 7812 [ISO 7812-1]. In general, the leading digits of such 102 card numbers, formally called the Issuer Identification Number (IIN), 103 indicate the issuing institution and the remainder of the number 104 identifies the individual card or account holder. The institution 105 prefix is sometimes referred to as the BIN (Bank Identification 106 Number), although it applies to more than banks, and the entire 107 number is somtimes known as the PAN (Primary Account Number), even 108 though these numbers are also used for secondary and other account 109 and identification numbers. Card numbers are generally issued in 110 connection with "brands" such as VISA, MasterCard, American Express, 111 JCB, Discover, Dinners Club, Air Travel Card, etc. 113 There has been no way, given a card number, to automatically find any 114 Internet site related to the card issuer, the card brand, or other 115 card facilities. In particular, the SET protocol [SET] defined by 116 VISA, MasterCard, and others, defines a means for cardholders, when 117 required, to obtain X.509 compliant certificates to attest to the 118 cardholder's authenticity but does not specify how to locate the 119 appropriate certification authority. Other protocol may require that 120 other facilities based on card number be reached over the Internet. 122 An means of automatically mapping such identification numbers into 123 domain names means that as soon as a number is know (due to user 124 account number entry or selection for a list of previous entered 125 PANs, for example), the ability would be present to easily attempt to 126 contact facilities on the Internet for that card. Thus web 127 browsers/wallets could, for example, provide "go to card brand", "get 128 a SET certificate", "go to issuing bank", etc., buttons whenever an 129 IS 7812 identification number is known. 131 1.1 SET CA Location 133 The most urgent potential need today is to locate SET Certification 134 Authorities (CAs). 136 In some cases, cardholders will be given URLs in mailings from the 137 card issuer or on their card itself. However, there will be other 138 cases, such as older cards that have not had a CA URL added or a card 139 for which the URL has changed due to bank mergers or splits or DNS 140 changes. Furthermore, in certification authority interaction, the 141 user will be required to supply their full account number in any case 142 and the requirement that they also manually enter a URL means 143 additional effort and opportunity for error. Note also that ISO 7812 144 account numbers have a built in check digit to catch most 145 typographical errors while URLs do not. 147 The system described in this draft permits SET Certification 148 Authority location without these problems. 150 1.2 ISO 7812 Details 152 Formally, ISO 7812 identification card numbers are divided as 153 follows: 155 1 2-6 7-v last 156 +-----+-------------------+-----------+-------------+ 157 | MII | issuer identifier | | | 158 +-----+-------------------+ account # | check digit | 159 | issuer identification # | | | 160 +-------------------------+-----------+-------------+ 161 | ISO 7812 identification number | 162 +---------------------------------------------------+ 163 MII = Major Industry Identifier as follows 164 0 - for ISO/TC 68 and other industry assignments 165 1 - airlines 166 2 - airlines and other industry assignments 167 3 - travel and entertainment 168 4/5 - banking/financial 169 6 - merchandizing and banking 170 7 - petroleum 171 8 - telecommunications and other industry assignments 172 9 - for national assignment 174 If the number starts with 9, the next three digits are the numeric 175 country code as defined in ISO 3166 and the remainder of the number 176 is as defined by that national standards body for that country. 178 Account numbers are variable length up to a maximum of 12 digits. 180 The check digit is calculated modulo 10 by the Luhn formula over all 181 the preceeding digits as specified in ISO 7812. 183 2. Inverse Number Mapping and Wildcards 185 When numbers are allocated in lexically hierarchical blocks so that a 186 prefix or suffix of digits is a meaningful division, the DNS wildcard 187 feature can be used to provide a convenient delgation and lookup 188 mechanism when the numbers and prefixes/suffixes are variable length. 189 In this regard, it is important to remember that more specific names 190 override less specific ones for DNS wildcards. 192 Domain names start with the most significant label on the right and 193 go to less significant labels as you go left while in card numbers 194 the leading or left most digits are the most significant while the 195 trailing or right most digits are less significant. Thus, the digits 196 must be reversed to match the card number and DNS naming systems and 197 the digits must be interspersed with dots to provide hierarchical 198 division into DNS domains. 200 Note that the transformed, reversed card number need not be exposed 201 to users but could be generated internally by software in an 202 automatic fashion. 204 For example, currently the American Express card brand is the only 205 one using numbers starting with 37. However, this is not a guarantee 206 for all time and it could be that at some point BIN numbers starting 207 with 37 would be assigned to a different brand. If you are looking 208 up facility "z" for card number 37012345678 (not a valid American 209 Express number), you could do a retrieval with a name like 210 3.2.1.0.7.3.z.card.reg.int. A wild card RR with the name 211 *.7.3.z.card.reg.int would match this and would appear in the 212 response with its name expanded to the specific name asked for, but 213 only if there were no more specific name. If there were a 214 3.2.1.0.7.3.z.card.reg.int specific name, for instance, it would 215 always be chosen in preference to the *.7.3.xz wildcard in this case 216 because it is a more exact match. On the other hand, if a retrieval 217 were done for 7.7.7.7.7.3.z.card.reg.int, it would get the more 218 general *.7.3.z.card.reg.int wild card since it does not match the 219 more exact wildcard. (The situation is generally somewhat more 220 complex than indicted here because additional intermediate length 221 wildcards may be needed. See the Appendix for a more complete 222 example zone.) 224 3. Card Domain Names Specified 226 Subdomains are defined within the card.reg.int domain for access to 227 the brand, the SET certification authority, and the card issuer. 228 Additional subdomains may be added if additional facilities 229 differently indexed by the card number require access. 231 To find a facility, you need to (1) get the BIN, (2) reverse the 232 order of these digits, and (3) put a dot between each digit and add 233 the appropriate facility suffix as shown below. The financial 234 transaction identification number MUST be truncated to avoid 235 revealing the full number in the DNS queries. 237 Sections 3.1 and 3.2 give further details on the facilities 238 available, section 3.3 discusses what to do about banks which are not 239 on line, and section 3.4 discusses what to do if the BIN is too 240 specific or not specific enough. 242 None of the facility pointers obtained via these means need be 243 exclusive and these financial identification card related Internet 244 facilities may have other names and URLs that will also work. These 245 facilities are intended to supplement, not necesarily replace, the 246 direct communication of domain names and URLs from financial 247 institutions to their customers. 249 3.1 Card Brand and Issuer Pointers 251 The card brand and issuer home pages can be located by creating the 252 numeric portion as above and appending ".brand.card.reg.int" or 253 ".issuer.card.reg.int" respectively. A CNAME RR will be stored at 254 that name pointing to the actual domain name for the home page. A 255 CNAME is chosen, rather than having specific "A" RRs pointing to 256 host(s), "MX" RRs pointing to mail servers, etc., to minimize the 257 update load on the card.reg.int domain. Changes in the serving host, 258 mail servers, etc., need only be made under the facility's domain 259 name, which the CNAME points to, rather than also under card.reg.int. 261 For example, the brand for the card 551204..., a MasterCard card, can 262 be found by browsing at 4.0.2.1.5.5.brand.card.reg.int. and the 263 issuer for the card 471922..., a VISA card, can be found by browsing 264 at 2.2.9.1.7.4.issuer.reg.card.int. These domain names can be 265 automatically generated from a card number and need not be exposed to 266 ordinary users. 268 The Appendix shows possible initial content of the brand.card.reg.int 269 domain. There are relatively few brands and they are allocated to 270 moderately compact blocks of numbers with relatively few exceptions 271 not belonging to the block brand. So there will probably be under 272 2,000 entries in the brand.card.reg.int subdomain. 274 Since there are only a few tens of thousands of banks and other 275 issuers of significance in the world for financial transaction cards, 276 there should be well under 200,000 entries in the issuer.card.reg.int 277 subdomain. 279 Although at this time very large blocks of numbers are generally 280 allocated to brands (for example almost all card numbers starting 281 with 5 and 4 are MasterCard and Visa cards, respectively), some 282 numbers within these large blocks may be carved out by more specific 283 entries for other brands. 285 3.2 SET Certification Authority (CA) Pointers 287 A very high level description of the cardholder certificate issuance 288 procedure in SET [SET] is for a cardholderCInitRequest initialization 289 message to be sent to the CA, an initialization response received, 290 then a registrationFormRequest is sent to the CA and a either 291 registration form returned which the user fills in or a referral to 292 another CA is returned. The completed registration form is submitted 293 in a certificateRequest message to which there is a response which 294 can include the certificate or indicate it will be issued later or 295 indicate a failure. 297 The above sequence can occur over a variety of transports [SET-EIG] 298 including TCP and HTTP. TCP would be to the SET well known port 257, 299 unless some other port was mutually agreed on, but cardholder to CA 300 communication is normally expected to be HTTP. In HTTP, the sequence 301 is usually preceded by a kick-off message from the CA which is of 302 MIME type Application/SET-Registration-Initiation which activates a 303 SET wallet. 305 There are three pointers provided in connection with CAs, one for the 306 CA general web page for browsing, one derived URL that can be hit to 307 produce the SET certificate issuance kick-off message, and a derived 308 URL that can be used to post the initial cardholderCInitRequest if a 309 kick-off cycle is not needed. 311 The certification authority home page can be found as described in 312 3.1 above for brands and issuers, except that the suffix is 314 .set-ca.card.reg.int. 316 A CNAME will also be used in this subdomain. At this time it is not 317 clear in how many cases a certification authority will correspond to 318 a single BIN, to a brand, to blocks of BINs, or even to part of a BIN 319 (see section 3.4). Note that the wild card mechanism can easily 320 accommodate arrangements such as a default certification authority 321 for a brand with specific CAs for some BINs within that brand. 323 To determine the URLs to hit for the SET certificate issuance wake up 324 message [SET-EIG], take the CA domain name as above, prefix it with 325 "http://", and suffix it with "/SET-Registration-Initiation". For 326 some purposes, the wake up message may not be necessary. In that 327 case, the cardholderCInitRequest SET message [SET] can be POSTed 328 directly to a similar URL but with the suffix of 329 /cardholderCInitRequest. 331 Suffix to Domain Name Action 333 /SET-Registration-Initiation Certificate Request Wakeup 334 /cardholderCInitRequest SET msg to start cert. req. 336 Note that no explicit DNS retrieval is necessary. In initiating a 337 cardholder certificate application for card number 8765432109, you 338 mechanically transform the number into a URL and go. In this case 339 that would be, to start with a kick-off, 341 . 343 3.3 Financial Institutions Not On Line 345 Some numbers are allocated to institutions that do not have a network 346 presence. In some of those cases, a wildcard will provide an 347 appropriate pointer, say to a brand supplied bank lookup page that 348 provides telephone number and address to contact the bank. However, 349 in cases where the next higher level wildcard would provide 350 inappropriate pointers for such institutions, it will be necessary in 351 some cases to add entries for such numbers which are CNAMEed to 352 "not-on-line.card.reg.int" which will not exist. Thus an appropriate 353 error message will be generated. 355 3.4 BIN Ambiguity 357 For the facilities under card.reg.int defined thus far in this 358 document, the BIN is defined as the first six digits of the account 359 number. In many cases an issuer or certification authority is 360 defined by fewer digits. This is no problem as a wild card can be 361 used to match all extensions of this shorter prefix. However, cases 362 where six digits are insufficient need special handling as describe 363 below. In the future, there might be facilities added under 364 card.reg.int that are accessed via classes of ISO 7812 numbers not 365 subject to this six digit security limitation. 367 If multiple institutions have decided to share a BIN, there are 368 several ways it can be handled. For the issuer web page either (1) 369 the banks sharing the BIN can run a common web page with links to 370 their individual pages on it or (2) if they are all the same brand, 371 the brand can run such a multi-issuer referral page at the BIN or, in 372 some cases, at a higher level wildcard or (3) in the unlikely event 373 that they are different brands, the card.reg.int maintenance agency 374 can run a page providing access to the different sub-BIN issuers. A 375 multiple issuer home page could just have names, icons, and links to 376 the separate institutions or more complex indexing if it covered many 377 banks. While this problem in not expected to arise for the 378 brand.card.reg.int subdomain, similar solutions apply if it does. 380 In the cases where a URL is derived to access SET certification 381 authority facilities, and the BIN is ambiguous, a different 382 implementation is used. In particular, instead of a human looking at 383 a web page, we may have an application trying to get a cardholder 384 certificate. However, when the registration process reaches the 385 point of sending the CA a registration form request, that request is 386 accompanied (securely) by the full account number. The registration 387 form response can have, instead of a registration form, a referral to 388 a different URL. Thus, the certification authority could be simply a 389 secure referral program that uses as much of the identification 390 number as it wishes, quite possibly more than the fist six digits, to 391 determine where to forward the cardholder application. 393 4. Security Considerations 395 This document concerns a means to map ISO 7812 financial 396 identification numbers into the Domain Name System (DNS) so that card 397 related facilities on the Internet can be automatically located. The 398 security of the resulting pointers is dependent on the integrity of 399 the card.reg.int maintenance agency and the security of the DNS, 400 including the use of security extensions [RFC 2065]. However, note 401 that when used in connection with SET certificate issuance, the SET 402 security mechanisms provide strong protection against spoofing or 403 compromise of sensitive information even if the DNS were subverted. 405 For currently existing types of ISO 7812 numbers care should be taken 406 in making DNS queries that an entire sensitive identification number 407 is NOT used. Since DNS queries are not encrypted, this would expose 408 the card number within the Internet. No more than the initial six 409 digits should be used. 411 References 413 [ISO 3166] - Codes for the representation of names of countries. 415 [ISO 7812-1] - Identification card - Identification of Issuers. 417 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 418 November 1987 420 [RFC 1035] - Domain Names - Implementation and Specifications, P. 421 Mockapetris, November 1987. 423 [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. 424 Kaufman, January 1997. 426 [SET] - Secure Electronic Transaction (SET) Specification, Version 427 1.0, May 31, 1997, available from . 428 Book 1: Business Description 429 Book 2: Programmer's Guide 430 Book 3: Formal Protocol Definition 432 [SET-EIG] - External Interface Guide to SET Secure Electronic 433 Transaction, September 24, 1997, available from 434 . 436 Author's Address 438 Donald E. Eastlake 3rd 439 CyberCash, Inc. 440 318 Acton Street 441 Carlisle, MA 01741 USA 443 Telephone: +1 978 287 4877 444 +1 703 620-4200 (main office, Reston, VA) 445 FAX: +1 978 371 7148 446 EMail: dee@cybercash.com 448 Expiration and File Name 450 This draft expires September 1998. 452 Its file name is draft-eastlake-card-map-02.txt. 454 Appendix: Initial Brand Pointers 456 This table shows the initial brand name pointers that might be 457 installed in the BRAND.card.reg.int domain. 459 Initial Name CNAME 461 *.1.brand.card.reg.int www.air-travel-card.com 462 *.3.brand.card.reg.int default.card.reg.int 463 *.0.3.brand.card.reg.int www.dinersclub.com 464 *.6.0.3.brand.card.reg.int www.dinersclub.com 465 *.9.6.0.3.brand.card.reg.int www.jcb.co.jp 466 *.8.0.3.brand.card.reg.int www.dinersclub.com 467 *.8.8.0.3.brand.card.reg.int www.jcb.co.jp 468 *.1.3.brand.card.reg.int www.jcb.co.jp 469 *.3.3.brand.card.reg.int www.americanexpress.com 470 *.3.3.3.brand.card.reg.int www.americanexpress.com 471 *.7.3.3.3.brand.card.reg.int www.jcb.co.jp 472 *.5.3.brand.card.reg.int www.jcb.co.jp 473 *.6.3.brand.card.reg.int www.dinersclub.com 474 *.7.3.brand.card.reg.int www.americanexpress.com 475 *.8.3.brand.card.reg.int www.dinersclub.com 476 *.4.brand.card.reg.int www.visa.com 477 *.5.brand.card.reg.int www.mastercard.com 478 *.6.brand.card.reg.int default.card.reg.int 479 *.0.6.brand.card.reg.int default.card.reg.int 480 *.1.0.6.brand.card.reg.int default.card.reg.int 481 *.1.1.0.6.brand.card.reg.int www.novus.com 483 (MasterCard actually only has numbers starting with 51, 52, 53, 54, 484 55, and 56 but until some other brand actually has cards issued with 485 a number starting with a 5, there is no reason to go to any more 486 detail in the wildcard. JCB is actually 3528, not all of 35* but the 487 same reasoning applies.)