idnits 2.17.1 draft-eastlake-card-map-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines 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 19 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 177 has weird spacing: '...irlines and o...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1999) is 9045 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) == Missing Reference: 'ISO 7812' is mentioned on line 516, but not defined == Missing Reference: 'ISO 7816' is mentioned on line 515, but not defined == Unused Reference: 'RFC 1034' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC 2535' is defined on line 638, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 7816-5' ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET-EIG' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 IBM 3 Expires January 2000 July 1999 4 draft-eastlake-card-map-06.txt 6 ISO 7812/7816 Numbers and the Domain Name System (DNS) 7 --- --------- ------- --- --- ------ ---- ------ ----- 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This draft, file name draft-eastlake-card-map-06.txt, is intended to 14 be become an Informational RFC. Distribution of this document is 15 unlimited. Comments should be sent to the author. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To view the entire list of current Internet-Drafts, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories as listed at . 39 Abstract 41 There are a variety of servers, web pages, and the like, which 42 holders of ISO 7812 financial transaction identification card (i.e., 43 credit/debit card) numbers and ISO 7816 smart card or related numbers 44 may need to locate on the Internet. For example, some systems assume 45 a smart card holder can contact the issuer of a smart card 46 application for maintenance and update functions and the SET protocol 47 assumes that a card holder can locate the appropriate certification 48 authority to obtain a card holder certificate. This document 49 specifies a method using the DNS as an important element in locating 50 card related facilities on the Internet by mapping ISO 7812 and ISO 51 7816 number systems into domain names within in the card.reg.int 52 domain. 54 Disclaimer 56 The methods proposed herein have not been endorsed by the issuers and 57 registries of ISO 7812 and 7816 numbers. 59 Acknowledgment 61 Suggestions from the following persons, listed in alphabetic order, 62 have been incorporated in this document and are gratefully 63 acknowledged: 65 Doug Beattie, Electronic Commerce Consultants 67 Dave Burdett, Commerce One 69 Brian Carpenter, IBM 71 Robert Elz, University of Melbourne 73 Tony Lewis, VISA International 75 Table of Contents 77 Status of This Document ...................................1 79 Abstract...................................................2 80 Disclaimer ................................................2 81 Acknowledgment ............................................2 83 Table of Contents..........................................3 85 1. Introduction............................................4 86 1.1 ISO 7812 Details ......................................4 87 1.2 ISO 7816 Details ......................................5 88 1.2.1 ISO 7816 '0'-'9' Prefixes ...........................6 89 1.2.2 ISO 7816 'A' Prefixes ...............................6 90 1.2.3 ISO 7816 'D' Prefixes ...............................7 91 1.2.4 ISO 7816 'B', 'C', and 'E' Prefixes .................7 92 1.2.5 ISO 7816 'F' Prefixes ...............................7 94 2. Inverse Number Mapping and Wildcards....................8 96 3. Card Domain Names Specified.............................9 97 3.1 ISO 7812 Card Brand, Issuer, and Acquirer Pointers ....9 98 3.2 ISO 7812 Acquirer Facilities .........................10 99 3.3 ISO 7812 SET Certification Authority Pointers ........10 100 3.3.1 The SET Certificate Issuance Process ...............10 101 3.3.2 Finding SET Certificate Authorities ................11 102 3.4 ICON Location ........................................12 103 3.5 Similar Proprietary Systems ..........................12 104 3.6 ISO 7816 Application IDs .............................13 105 4. Financial Institutions Not On Line ....................13 106 5. ISO 7812 BIN Ambiguity ................................13 107 5.1 Ambiguous BIN Web Page Access ........................14 108 5.2 Ambiguous BIN SET CA Access ..........................14 109 6. Security Considerations ...............................14 111 References................................................16 113 Author's Address..........................................17 114 Expiration and File Name .................................17 116 Appendix: Initial ISO 7812 Brand Pointers.................18 118 1. Introduction 120 Financial transaction cards such as credit and debit cards are 121 identified by numbers issued in conjunction with ISO standard 7812 122 [ISO 7812-1] and applications that run on ISO smart cards are 123 identified by numbers issued in conjunction with ISO standard 7816 124 [ISO 7816-5]. In general, the leading digits of such numbers indicate 125 the category and/or issuing institution and the remainder of the 126 number provides further identification. 128 There has been no way, given such a number, to automatically find an 129 Internet site related to the card issuer, the card brand, or other 130 card facilities. For example, the SET protocol [SET] defined by VISA, 131 MasterCard, and others, defines a means for cardholders, when 132 required, to obtain X.509v3 compliant certificates to attest to the 133 cardholder's authenticity. But the SET standard does not specify how 134 to locate the appropriate certification authority. Some operations 135 in connections with smart card resident applications, such as 136 resetting certain error conditions on a stored value card, may 137 require contacting the issuer. Other protocols may require that other 138 facilities based on card number be reached over the Internet. 140 A means of automatically mapping such identification numbers into 141 domain names means that as soon as a number is known (due to user 142 smart card insertion, the reading of a magnetic stripe, or user 143 selection from a list of previous entered credit cards, for example), 144 the ability would be present to easily attempt to contact facilities 145 on the Internet for that number. Thus web browsers/wallets could 146 provide "go to issuer", "go to brand", "get a SET certificate", 147 etc., buttons whenever an IS0 7812/7816 identification number is 148 known. 150 1.1 ISO 7812 Details 152 Under ISO 7812, card numbers are decimal and the first 6 digits are 153 formally known as the Issuer Identification Number or IIN. This six 154 digit prefix is sometimes referred to as the BIN (Bank Identification 155 Number), although it applies to more than banks, and the entire 156 number is sometimes known as the PAN (Primary Account Number), even 157 though these numbers are also used for secondary accounts, Merchant 158 accounts, and other account and identification numbers. Card numbers 159 are frequently issued in connection with "brands" such as VISA, 160 MasterCard, American Express, JCB, Discover, Dinners Club, Air Travel 161 Card, etc. 163 Formally, ISO 7812 identification card numbers are divided as 164 follows: 166 1 2-6 7-> last 167 +-----+-------------------+-----------+-------------+ 168 | MII | issuer identifier | | | 169 +-----+-------------------+ account # | check digit | 170 | issuer identification # | | | 171 +-------------------------+-----------+-------------+ 172 | ISO 7812 identification number | 173 +---------------------------------------------------+ 174 MII = Major Industry Identifier as follows 175 0 - for ISO/TC 68 and other industry assignments 176 1 - airlines 177 2 - airlines and other industry assignments 178 3 - travel and entertainment 179 4/5 - banking/financial 180 6 - merchandizing and banking 181 7 - petroleum 182 8 - telecommunications and other industry assignments 183 9 - for national assignment 185 If the number starts with 9, the next three digits are the numeric 186 country code as defined in [ISO 3166] and the remainder of the number 187 is as defined by that national standards body for that country. 189 Account numbers are variable length up to a maximum of 12 digits so 190 the maximum total length is 19 bytes. 192 The check digit is calculated modulo 10 by the Luhn formula over all 193 the preceding digits as specified in [ISO 7812]. 195 The global registration agency for [ISO 7812] Issuer Identification 196 Numbers is the American Bankers Association (www.aba.com) but 197 application for an IIN must generally be made through a national 198 standards body. 200 1.2 ISO 7816 Details 202 ISO smart cards have applications on them each identified by a 203 hexadecimal Application Identifier (AID) BCD encoded into a maximum 204 of 16 bytes. In the past, most such cards have had a single 205 application but multiapplication cards are expected to be more common 206 in the future. 208 The first hex digit of the AID indicates the type of AID prefix as 209 listed below followed by details on each type. In general, the AID 210 prefix is followed a variable length "Proprietary application 211 identification extension" (PIX) under the control of the issuer 212 identified by the prefix. 214 0-9 An ISO 7812 IIN. 215 A International registration. 216 B-C Reserved for ISO. 217 D National registration. 218 E Reserved for ISO. 219 F Proprietary non-registered 221 1.2.1 ISO 7816 '0'-'9' Prefixes 223 AIDs with a prefix of '0' through '9' use ISO 7812 IINs for the 224 prefix (see section 1.1 above). 226 +-------------------------+--------+----------------------------+ 227 | ISO 7812 | | Proprietary application | 228 | issuer identification # | 'FF' | identifier extension (PIX) | 229 +-------------------------+--------+----------------------------+ 230 | Application identifier (AID), 2-16 bytes | 231 +---------------------------------------------------------------+ 233 [ISO 7816] is designed to be independent of IIN length and specifies 234 that if the IIN length is odd, it should be padded up the next full 235 byte by suffixing a hex 'F' nibble. 237 1.2.2 ISO 7816 'A' Prefixes 239 In AIDs with a prefix of 'A' (i.e., binary 1010), the prefix is 240 followed by 36 bits of Registry provider number as 9 BCD digits. 241 Values in these 9 nibbles that do not corresponding to a decimal 242 digits are reserved for ISO. 244 +---------------------------------------------------------+ 245 | Registered Application | Proprietary application | 246 | provider identifier (RID) | identifier extension (PIX) | 247 | 5 bytes | <= 11 bytes | 248 +---------------------------------------------------------+ 249 | Application identifier (AID), 1-16 bytes | 250 +---------------------------------------------------------+ 252 The registration authority for RIDs is 254 Tele Denmark (www.teledanmark.dk> 255 Attn: ISO/IEC 7816-5 Registration Authority 256 Teglholmsgade 1 257 1790 Copenhagen V 258 Denmark 260 1.2.3 ISO 7816 'D' Prefixes 262 The RID consists of the 4 bit D prefix (binary 1101), the country 263 code in 12 bits as 3 BCD digits coded according to the numeric 264 country codes in [ISO 3166], and 24 additional bits as specified by 265 the national standards body with BCD coding recommended. 267 +---------------------------------------------------------+ 268 | Registered Application | Proprietary application | 269 | provider identifier (RID) | identifier extension (PIX) | 270 | 5 bytes | <= 11 bytes | 271 +---------------------------------------------------------+ 272 | Application identifier (AID), 1-16 bytes | 273 +---------------------------------------------------------+ 275 1.2.4 ISO 7816 'B', 'C', and 'E' Prefixes 277 Prefixes 'B', 'C', and 'E' are reserved for future use by ISO and not 278 further specified. 280 1.2.5 ISO 7816 'F' Prefixes 282 Prefix 'F' indicates a proprietary non-registered AID. Because of 283 this, the same 'F' prefixed AID could be used by different 284 application providers for different applications. 286 +------------------------------------------------------+ 287 | Application Label | 288 +------------------------------------------------------+ 289 | Proprietary application identifier (AID), 1-16 bytes | 290 +------------------------------------------------------+ 292 2. Inverse Number Mapping and Wildcards 294 When numbers are allocated in lexically hierarchical blocks so that a 295 prefix or suffix of digits is a meaningful division, the DNS wildcard 296 feature can be used to provide a convenient delegation and lookup 297 mechanism. This works even when the numbers and prefixes/suffixes 298 are variable length. In this regard, it is important to remember that 299 more specific names override less specific ones for DNS wildcards. 301 Domain names start with the most significant label on the right and 302 go to less significant labels as you go left while in ISO 7812 and 303 7816 numbers the leading or left most digits are the most significant 304 while the trailing or right most digits are less significant. Thus, 305 the digits must be reversed to match the card number and DNS naming 306 systems and the digits must be interspersed with dots to provide 307 hierarchical division into DNS domains. 309 Note that the transformed, reversed number need not be exposed to 310 users but could be generated internally by software in an automatic 311 fashion. 313 For example, currently the American Express card brand is the only 314 one using [ISO 7812] numbers starting with 37. However, this is not 315 a guarantee for all time and it could be that at some point some BIN 316 numbers starting with 37 would be assigned to a different brand. If 317 you are looking up facility "z" for card number 37012345678 (not a 318 valid American Express number), you could do a retrieval with a name 319 like 3.2.1.0.7.3.z.card.reg.int based on the first six digits of the 320 number. A wild card RR with the name *.7.3.z.card.reg.int would match 321 this and would appear in the response with its name expanded to the 322 specific name asked for, but only if there were no more specific 323 name. If there were a 3.2.1.0.7.3.z.card.reg.int specific name, for 324 instance, it would always be chosen in preference to the 325 *.7.3.card.reg.int wildcard in this case because it is a more exact 326 match. Thus more specific values can punch out holes in ranges 327 established by shorter, less specific prefixes. On the other hand, 328 if a retrieval were done for 7.7.7.7.7.3.z.card.reg.int, it would get 329 the more general *.7.3.z.card.reg.int wild card since it does not 330 match the more exact wildcard. (The situation is generally a little 331 more complex than indicted here because additional intermediate 332 length wildcards may be needed. See the Appendix for a more complete 333 example zone.) 335 3. Card Domain Names Specified 337 Subdomains are currently defined within the card.reg.int domain as 338 follows in alphabetic order: 340 acquirer.card.reg.int - ISO 7812 card acquirers 341 aid.card.reg.int - ISO 7816 application identifiers 342 brand.card.reg.int. - ISO 7812 card brands. 343 issuer.card.reg.int. - ISO 7812 card issuers. 344 set-ca.card.reg.int. - ISO 7812 SET Certification Authorities. 346 To find a facility, you need to (1) get the number, (2) reverse the 347 order of these digits, and (3) put a dot between each digit and add 348 the appropriate facility suffix as shown below. [ISO 7812] financial 349 transaction card identification numbers generally must be truncated 350 to six digits if revealing the full number in the DNS queries would 351 be a security problem. Generally revealing the entire number in a 352 DNS query is not a problem for [ISO 7816] AIDs. 354 None of the facility pointers obtained via these means need be 355 exclusive and these card related Internet facilities may have other 356 names and URLs that will also work. These facilities are intended to 357 supplement, not necessarily replace, direct communication of domain 358 names and URLs from financial institutions to their customers. 360 3.1 ISO 7812 Card Brand, Issuer, and Acquirer Pointers 362 The card brand and issuer home pages would be located by creating the 363 numeric portion as above and appending ".brand.card.reg.int" or 364 ".issuer.card.reg.int" respectively. A CNAME RR will be stored at 365 that name pointing to the actual domain name for the home page. A 366 CNAME is chosen, rather than having specific "A" RRs pointing to 367 host(s), "MX" RRs pointing to mail servers, etc., to minimize the 368 update load on the card.reg.int sub-domains. Changes in the serving 369 host, mail servers, etc., need only be made under the facility's 370 domain name, which the CNAME points to, rather than also under 371 card.reg.int. 373 For example, the brand for the card 551204..., a MasterCard card, 374 would be found by browsing at 4.0.2.1.5.5.brand.card.reg.int. and the 375 issuer for the card 471922..., a VISA card, would be found by 376 browsing at 2.2.9.1.7.4.issuer.reg.card.int. These domain names can 377 be automatically generated from a card number and need not be exposed 378 to users. 380 The Appendix shows possible initial content of the brand.card.reg.int 381 domain. There are relatively few brands and they are allocated to 382 moderately compact blocks of numbers with relatively few exceptions 383 not belonging to the block brand. So there will probably be under 384 2,000 entries in the brand.card.reg.int subdomain. 386 Since there are only a few tens of thousands of banks and other 387 issuers of significance in the world for financial transaction cards, 388 there should be well under 200,000 entries in the issuer.card.reg.int 389 subdomain. 391 Although at this time very large blocks of numbers are generally 392 allocated to brands (for example almost all card numbers starting 393 with 5 and 4 are MasterCard and Visa cards, respectively), some 394 numbers within these large blocks may be carved out by more specific 395 entries for other brands. 397 3.2 ISO 7812 Acquirer Facilities 399 Generally, merchants are assigned merchant IDs from the space of PANs 400 by their acquirer. Acquirer facilities can be located from such 401 numbers using the .acquirer.card.reg.int suffix. 403 3.3 ISO 7812 SET Certification Authority Pointers 405 This section describes the SET certificate issuance process and how 406 card.reg.int could be used to find certification authorities. 408 3.3.1 The SET Certificate Issuance Process 410 A very high level description of the cardholder certificate issuance 411 procedure in SET [SET] is as follows: (1) a cardholderCInitRequest 412 initialization message is sent by cardholder software to the 413 Certificaiton Authority (CA), (2) an initialization response 414 received, (3) a registrationFormRequest is sent to the CA and either 415 (4a) a registration form returned which the user fills in or (4b) a 416 referral to another CA is returned. (5) The completed registration 417 form is submitted in a certificateRequest message to which there is 418 (6) a response which can include the certificate or indicate it will 419 be issued later or indicate a failure. 421 The above sequence can occur over a variety of transports [SET-EIG] 422 including TCP and HTTP. TCP would be to the SET well known port 257, 423 unless some other port was mutually agreed on, but cardholder to CA 424 communication is normally expected to be HTTP. In HTTP, the sequence 425 is usually preceded by a kick-off message from the CA which is of 426 MIME type Application/SET-Registration-Initiation which activates a 427 SET wallet. 429 3.3.2 Finding SET Certificate Authorities 431 In some cases, cardholders will be given SET certification Authority 432 URLs in mailings from the card issuer or on their card itself. 433 However, there will be other cases, such as older cards that have not 434 had a CA URL added or a card for which the URL has changed due to 435 bank mergers or splits or DNS changes. Furthermore, in certification 436 authority interaction, the user will be required to supply their full 437 account number in any case and the requirement that they also 438 manually enter a URL means additional effort and opportunity for 439 error. Note also that [ISO 7812] account numbers have a built in 440 check digit to catch most typographical errors while URLs do not. 441 Thus the ability to automatically determine a SET CA URL from a card 442 number should be very helpful. 444 There are three pointers provided in connection with CAs, one for the 445 CA general web page for browsing, one derived URL that can be hit to 446 produce the SET certificate issuance kick-off message, and a derived 447 URL that can be used to post the initial cardholderCInitRequest if a 448 kick-off cycle is not needed. 450 The certification authority home page can be found as described in 451 3.1 above for brands and issuers, except that the suffix is 453 ".set-ca.card.reg.int". 455 A CNAME will also be used in this subdomain. At this time it is not 456 clear in how many cases a certification authority will correspond to 457 a single BIN, to a brand, to blocks of BINs, or even to part of a BIN 458 (see section 3.4). Note that the wild card mechanism can easily 459 accommodate arrangements such as a default certification authority 460 for a brand with specific CAs for some BINs within that brand. 462 To determine the URLs to hit for the SET certificate issuance wake up 463 message [SET-EIG], take the CA domain name as above, prefix it with 464 "http://", and suffix it with "/SET-Registration-Initiation". An 465 HTTP GET should be used in hitting that URL. 467 For some purposes, the wake up message may not be necessary. In that 468 case, the cardholderCInitRequest SET message [SET] can be HTTP POSTed 469 directly to a similar URL but with the suffix of 470 /cardholderCInitRequest. 472 Suffix to Domain Name Action 474 /SET-Registration-Initiation Certificate Request Wakeup 475 /cardholderCInitRequest SET msg to start cert. req. 476 / human browsable CA home page 478 Note that no explicit extra DNS retrieval is necessary. In 479 initiating a cardholder certificate application for card number 480 8765432109, you can mechanically transform the number into a URL and 481 go. In this case that would be, to start with a kick-off, 483 . 485 3.4 ICON Location 487 For many of the facilities locatable via card.reg.int, some user 488 interface software will want to be able to display an image or icon. 489 Standard suffixes to the computed domain name of the facility are 490 recommended, as listed below, to make the default location of such 491 icons easier. 493 Suffix to Domain Name Image Size in Pixels 495 /icons/exsmall.gif 32 x 32 or 32 x 20 496 /icons/small.gif 53 x 33 497 /icons/medium.gif 103 x 65 498 /icons/large.gif 180 x 114 499 /icons/exlarge.gif 263 x 166 501 The larger dimension above is horizontal and the smaller is vertical. 502 The extra small version is permitted to be a 32x32 square which is a 503 common desk top operating system icon size. It is recommended that 504 displaying the extra small size be avoided due to lower 505 recognizability is such small images. The color palette of the icons 506 should be limited to colors typically available in an 8 bit or 256 507 color environment. 509 The above file name, size, and color recommendations are similar to 510 those in Book 2 of the SET standards [SET]. 512 3.5 Similar Proprietary Systems 514 Some proprietary systems use numbers schemes similar to [ISO 7812] or 515 [ISO 7816]. For instance, an "Example" stored cash card system might 516 use card IDs that have the same structure and prefixes as [ISO 7812] 517 card numbers. Such schemes are welcome to use the techniques 518 described in this document for inverse look up via DNS but should 519 place the inverse tree under their proprietary domain name. For 520 instance, the hypothetical stored cash card system could use 521 ....card-number.example.com. 523 3.6 ISO 7816 Application IDs 525 Facilities based on [ISO 7816]bv application identifiers can be found 526 using the 528 suffix. While a subset of such IDs are structured like ISO 7812 529 PANs, nevertheless, they are likely to need different facilities so 530 no reference is made to the parts of the card.reg.int DNS tree 531 allocated for non-smart card use. 533 4. Financial Institutions Not On Line 535 Some numbers are allocated to institutions that do not have a network 536 presence. In some of those cases, a wildcard could provide an 537 appropriate pointer, say to a brand supplied bank lookup page that 538 provides telephone number and address or the like to contact the 539 bank. However, in cases where the next higher level wildcard would 540 provide inappropriate pointers for such institutions, it will be 541 necessary to add entries for such numbers which are CNAMEed to "not- 542 on-line.card.reg.int" which will not exist. Thus an appropriate 543 error message will be generated. 545 5. ISO 7812 BIN Ambiguity 547 For the facilities under card.reg.int using ISO 7812 numbers, the BIN 548 is defined as the first six digits of the account number. In many 549 cases an issuer or certification authority is defined by fewer 550 digits, for example the first four digits. This is no problem as a 551 wild card can be used to match all extensions of this shorter prefix. 552 However, cases where six digits are insufficient need special 553 handling as describe below. Such situations can arise due to 554 subdivision / subdelegation of a BIN for administrative reasons, due 555 to sale of part of a card population, as parts of bank mergers and 556 splits, etc. Additional digits can not be used in the DNS query 557 because they would reveal too much of the card number and thus be a 558 security risk. 560 5.1 Ambiguous BIN Web Page Access 562 If multiple institutions have decided to share a BIN, there are 563 several ways the situation can be handled. For the issuer web page 564 either (1) the institutions sharing the BIN can run a common web page 565 with links to their individual pages on it or (2) if they are all the 566 same brand, the brand can run such a multi-issuer referral page at 567 the BIN or, in many cases, at a higher level wildcard or (3) in the 568 event that they are different brands, the card.reg.int maintainer can 569 run a page providing access to the different sub-BIN issuers. A 570 multiple issuer home page could just have names, icons, and links to 571 the separate institutions or more complex indexing or search 572 facilities if it covered many banks. While this problem in not 573 expected to arise for the brand.card.reg.int subdomain, similar 574 solutions apply if it does. 576 5.2 Ambiguous BIN SET CA Access 578 In the cases where a URL is derived to access SET certification 579 authority facilities, and the BIN is ambiguous, a more automated 580 solution is available. In particular, instead of a human looking at 581 a web page, we usually have an application trying to get a cardholder 582 certificate. In SET, when the registration process reaches the point 583 of sending the CA a registration form request, that request is 584 accompanied (securely) by the full account number. The registration 585 form response that is returned can have, instead of a registration 586 form, a referral to a different URL. Thus, the "certification 587 authority" could be simply a secure referral program that uses as 588 much of the identification number as it wishes, quite possibly more 589 than the fist six digits, to determine where to forward the 590 cardholder application. 592 Note that a brand could chose to run such a secure SET CA referral 593 facility at the brand level. 595 6. Security Considerations 597 This document concerns a means to map ISO 7812 financial card and ISO 598 7816 smart card application identification numbers into the Domain 599 Name System (DNS) so that card related facilities on the Internet can 600 be automatically located. The security of the resulting pointers is 601 dependent on the integrity of the card.reg.int maintainer and the 602 security of the DNS, including the use of security extensions [RFC 603 2535]. However, note that when used in connection with most smart 604 card application schemes and with SET certificate issuance, the 605 security mechanisms of the protocols used after communications is 606 established provide strong protection against spoofing or compromise 607 of sensitive information even if the DNS were subverted. 609 For currently existing types of ISO 7812 financial numbers, care 610 should be taken in making DNS queries that an entire sensitive 611 identification number is NOT used. Since DNS queries are not 612 encrypted, this would expose the card number within the Internet. No 613 more than the initial six digits may be used. (These consideration 614 do not generally apply to numbers based on ISO 7816 application 615 identifiers.) 617 References 619 [ISO 3166] - Codes for the representation of names of countries. 621 [ISO 7812-1] - Identification card - Identification of Issuers. 623 [ISO 7816-5] - Identification card - Integrated circuit(s) cards with 624 contacts - Numbering system and registration procedures of 625 application identifiers 627 Note: The International Standards Organization web site is at 628 . Final ISO standards, such as 3166, 7812, and 629 7816, are not generally available on the Internet and usually must 630 be purchased through national standards bodies. 632 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 633 November 1987 635 [RFC 1035] - Domain Names - Implementation and Specifications, P. 636 Mockapetris, November 1987. 638 [RFC 2535] - Domain Name System Security Extensions, D. Eastlake, 639 March 1999. 641 [SET] - Secure Electronic Transaction (SET) Specification, Version 642 1.0, May 31, 1997, available from . 643 Book 1: Business Description 644 Book 2: Programmer's Guide 645 Book 3: Formal Protocol Definition 647 [SET-EIG] - External Interface Guide to SET Secure Electronic 648 Transaction, September 24, 1997, available from 649 . 651 Author's Address 653 Donald E. Eastlake 3rd 654 IBM 655 65 Shindegan Hill Road, RR #1 656 Carmel, NY 10512 USA 658 Telephone: +1 914-784-7913 (w) 659 +1 914-276-2668 (h) 660 FAX: +1 914-784-3833 (w) 661 EMail: dee3@us.ibm.com 663 Expiration and File Name 665 This draft expires February 2000. 667 Its file name is draft-eastlake-card-map-06.txt. 669 Appendix: Initial ISO 7812 Brand Pointers 671 This table shows possible initial brand name pointers that might be 672 installed in the brand.card.reg.int domain. 674 Initial Name CNAME 676 *.1.brand.card.reg.int www.air-travel-card.com 677 *.3.brand.card.reg.int unknown-brand.card.reg.int 678 *.0.3.brand.card.reg.int www.dinersclub.com 679 *.6.0.3.brand.card.reg.int www.dinersclub.com 680 *.9.6.0.3.brand.card.reg.int www.jcb.co.jp 681 *.8.0.3.brand.card.reg.int www.dinersclub.com 682 *.8.8.0.3.brand.card.reg.int www.jcb.co.jp 683 *.1.3.brand.card.reg.int www.jcb.co.jp 684 *.3.3.brand.card.reg.int www.americanexpress.com 685 *.3.3.3.brand.card.reg.int www.americanexpress.com 686 *.7.3.3.3.brand.card.reg.int www.jcb.co.jp 687 *.5.3.brand.card.reg.int unknown-brand.card.reg.int 688 *.2.5.3.brand.card.reg.int unknown-brand.card.reg.int 689 *.8.2.5.3.brand.card.reg.int www.jcb.co.jp 690 *.6.3.brand.card.reg.int www.dinersclub.com 691 *.7.3.brand.card.reg.int www.americanexpress.com 692 *.8.3.brand.card.reg.int www.dinersclub.com 693 *.4.brand.card.reg.int www.visa.com 694 *.5.brand.card.reg.int www.mastercard.com 695 *.6.brand.card.reg.int unknown-brand.card.reg.int 696 *.0.6.brand.card.reg.int unknown-brand.card.reg.int 697 *.1.0.6.brand.card.reg.int unknown-brand.card.reg.int 698 *.1.1.0.6.brand.card.reg.int www.novus.com 700 (MasterCard actually only has numbers starting with 51 through 56 but 701 until some other brand with cards issued with ISO 7812 numbers 702 starting with a 5 are entered into the DNS zone, there is no reason 703 to go to any more detail in the wildcard.)