idnits 2.17.1 draft-bormann-cbor-tags-oid-07.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 July 2020) is 1364 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '85' on line 383 -- Looks like a reference, but probably isn't: '4' on line 383 -- Looks like a reference, but probably isn't: '6' on line 383 ** Downref: Normative reference to an Informational RFC: RFC 6256 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Standards Track S. Leonard 5 Expires: 4 January 2021 Penango, Inc. 6 3 July 2020 8 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 9 draft-bormann-cbor-tags-oid-07 11 Abstract 13 The Concise Binary Object Representation (CBOR, RFC 7049) is a data 14 format whose design goals include the possibility of extremely small 15 code size, fairly small message size, and extensibility without the 16 need for version negotiation. 18 The present document defines CBOR tags for object identifiers (OIDs). 19 It is intended as the reference document for the IANA registration of 20 the CBOR tags so defined. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 4 January 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Tag Factoring with OID Arrays and Maps . . . . . . . . . . . 6 60 6. Applications and Examples of OIDs . . . . . . . . . . . . . . 6 61 7. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 8 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 10.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 The Concise Binary Object Representation (CBOR, [RFC7049]) provides 73 for the interchange of structured data without a requirement for a 74 pre-agreed schema. RFC 7049 defines a basic set of data types, as 75 well as a tagging mechanism that enables extending the set of data 76 types supported via an IANA registry. 78 The present document defines CBOR tags for object identifiers (OIDs, 79 [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding 80 Rules (BER, [X.690]) specify binary encodings of both (absolute) 81 object identifiers and relative object identifiers. The contents of 82 these encodings can be carried in a CBOR byte string. This document 83 defines two CBOR tags that cover the two kinds of ASN.1 object 84 identifiers encoded in this way. The tags can also be applied to 85 arrays and maps for more articulated identification purposes. It is 86 intended as the reference document for the IANA registration of the 87 tags so defined. 89 1.1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 The terminology of RFC 7049 applies; in particular the term "byte" is 98 used in its now customary sense as a synonym for "octet". 100 2. Object Identifiers 102 The International Object Identifier tree [X.660] is a hierarchically 103 managed space of identifiers, each of which is uniquely represented 104 as a sequence of primary integer values [X.680]. While these 105 sequences can easily be represented in CBOR arrays of unsigned 106 integers, a more compact representation can often be achieved by 107 adopting the widely used representation of object identifiers defined 108 in BER; this representation may also be more amenable to processing 109 by other software making use of object identifiers. 111 BER represents the sequence of unsigned integers by concatenating 112 self-delimiting [RFC6256] representations of each of the primary 113 integer values in sequence. 115 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 116 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 117 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 118 relative to some object identifier known from context ([X.680] Clause 119 3.8.63). As a special optimization, BER combines the first two 120 integers in an absolute object identifier into one numeric identifier 121 by making use of the property of the hierarchy that the first arc has 122 only three integer values (0, 1, and 2), and the second arcs under 0 123 and 1 are limited to the integer values between 0 and 39. (The root 124 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 125 If X and Y are the first two integers, the single integer actually 126 encoded is computed as: 128 X * 40 + Y 130 The inverse transformation (again making use of the known ranges of X 131 and Y) is applied when decoding the object identifier. 133 Since the semantics of absolute and relative object identifiers 134 differ, this specification defines two tags: 136 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 137 object identifier (simply "object identifier" or "OID"). 139 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 140 object identifier (also "relative OID"). Since the encoding of each 141 number is the same as for [RFC6256] Self-Delimiting Numeric Values 142 (SDNVs), this tag can also be used for tagging a byte string that 143 contains a sequence of zero or more SDNVs. 145 2.1. Requirements on the byte string being tagged 147 A byte string tagged by TBD111 or TBD110 MUST be a syntactically 148 valid BER representation of an object identifier: A concatenation of 149 zero or more SDNV values, where each SDNV value is a sequence of one 150 or more bytes that all have their most significant bit set, except 151 for the last byte, where it must be unset; the first byte of each 152 SDNV cannot be 0x80 (which would be a leading zero in SDNV's base-128 153 arithmetic). 155 In other words: 157 * its first byte, and any byte that follows a byte that has the most 158 significant bit unset, MUST NOT be 0x80 (this requirement excludes 159 expressing the primary integer values with anything but the 160 shortest form) 162 * its last byte MUST NOT have the most significant bit set (this 163 requirement excludes an incomplete final primary integer value) 165 If either of these invalid conditions are encountered, the tag is 166 invalid. 168 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 169 their encoding would have at least one SDNV. This specification 170 permits empty relative object identifiers; they may still be excluded 171 by application semantics. 173 To enable the search for specific object ID values, it is RECOMMENDED 174 that definite length encoding (see Section 2.2.2 of [RFC7049]) is 175 used for the byte strings used as tag content for these tags. 177 The valid set of byte strings can also be expressed using regular 178 expressions on bytes, using no specific notation but resembling 179 [PCRE]. Unlike typical regular expressions that operate on character 180 sequences, the following regular expressions take bytes as their 181 domain, so they can be applied directly to CBOR byte strings. 183 For byte strings with tag TBD111: 185 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 187 For byte strings with tag TBD110: 189 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 191 A tag with tagged content that does not conform to the applicable 192 regexp is invalid. 194 3. Examples 196 3.1. Encoding of the SHA-256 OID 198 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 199 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 200 sha256(1) } 202 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 204 06 # UNIVERSAL TAG 6 205 09 # 9 bytes, primitive 206 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 207 # | 840 1 | 3 4 2 1 show component encoding 208 # 2.16 101 210 Figure 1: SHA-256 OID in BER 212 D8 6F # tag(111) 213 49 # 0b010_01001: mt 2, 9 bytes 214 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 216 Figure 2: SHA-256 OID in CBOR 218 3.2. Encoding of a MIB Relative OID 220 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 221 [RFC7388]), to which the following is added: 223 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 224 lowpanOutTransmits(29) } 226 Dotted Decimal Notation: .1.1.29 228 0D # UNIVERSAL TAG 13 229 03 # 3 bytes, primitive 230 01 01 1D # X.690 Clause 8.20 231 # 1 1 29 show component encoding 233 Figure 3: MIB relative object identifier, in BER 235 D8 6E # tag(110) 236 43 # 0b010_01001: mt 2 (bstr), 3 bytes 237 01 01 1D # X.690 Clause 8.20 239 Figure 4: MIB relative object identifier, in CBOR 241 This relative OID saves seven bytes compared to the full OID 242 encoding. 244 4. Discussion 246 Staying close to the way object identifiers are encoded in ASN.1 BER 247 makes back-and-forth translation easy; otherwise we would choose a 248 more efficient encoding. Object identifiers in IETF protocols are 249 serialized in dotted decimal form or BER form, so there is an 250 advantage in not inventing a third form. Also, expectations of the 251 cost of encoding object identifiers are based on BER; using a 252 different encoding might not be aligned with these expectations. If 253 additional information about an OID is desired, lookup services such 254 as the OID Resolution Service (ORS) [X.672] and the OID Repository 255 [OID-INFO] are available. 257 5. Tag Factoring with OID Arrays and Maps 259 TBD111 and TBD110 can tag CBOR arrays and maps. The idea is that the 260 tag is factored out from each individual byte string; the tag is 261 placed in front of the array or map instead. The tags TBD111 and 262 TBD110 are left-distributive. 264 When the TBD111 or TBD110 tag is applied to an array, it means that 265 the respective tag is imputed to all items in the array that are byte 266 strings. For example, when the array is tagged with TBD111, every 267 array item that is a binary string is an OID. 269 When the TBD111 or TBD110 tag is applied to a map, it means that the 270 respective tag is imputed to all keys in the map that are byte 271 strings. The values in the map are not considered specially tagged. 273 Array and map nesting is permitted. For example, a 3-dimensional 274 array of OIDs can be composed by using a single TBD111 tag, followed 275 by an array of arrays of arrays of binary strings. All such binary 276 strings are considered OIDs. 277 // That was part of the original proposal. I find it hard to imagine 278 // how to stop the influence of the tag deep into a nested structure. 279 // That's why I would rather limit this to one level (no nesting). 280 // But see the Figure below, which needs a nesting of two. Please 281 // discuss. 283 6. Applications and Examples of OIDs 285 6.1. X.500 Distinguished Name 287 Consider the X.500 distinguished name: 289 +==============================+=============+ 290 | Attribute Types | Attribute | 291 | | Values | 292 +==============================+=============+ 293 | c (2.5.4.6) | US | 294 +------------------------------+-------------+ 295 | l (2.5.4.7) | Los Angeles | 296 | s (2.5.4.8) | CA | 297 | postalCode (2.5.4.17) | 90013 | 298 +------------------------------+-------------+ 299 | street (2.5.4.9) | 532 S Olive | 300 | | St | 301 +------------------------------+-------------+ 302 | businessCategory (2.5.4.15) | Public Park | 303 | buildingName | Pershing | 304 | (0.9.2342.19200300.100.1.48) | Square | 305 +------------------------------+-------------+ 307 Table 1: Example X.500 Distinguished Name 309 Table 1 has four "relative distinguished names" (RDNs). The country 310 and street RDNs are single-valued. The second and fourth RDNs are 311 multi-valued. 313 The equivalent representations in CBOR diagnostic notation and CBOR 314 are: 316 111([{ h'550406': "US" }, 317 { h'550407': "Los Angeles", h'550408': "CA", 318 h'550411': "90013" }, 319 { h'550409': "532 S Olive St" }, 320 { h'55040f': "Public Park", 321 h'0992268993f22c640130': "Pershing Square" }]) 323 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 325 d8 6f # tag(111) 326 84 # array(4) 327 a1 # map(1) 328 43 550406 # 2.5.4.6 (4) 329 62 # text(2) 330 5553 # "US" 331 a3 # map(3) 332 43 550407 # 2.5.4.7 (4) 333 6b # text(11) 334 4c6f7320416e67656c6573 # "Los Angeles" 335 43 550408 # 2.5.4.8 (4) 336 62 # text(2) 337 4341 # "CA" 338 43 550411 # 2.5.4.17 (4) 339 65 # text(5) 340 3930303133 # "90013" 341 a1 # map(1) 342 43 550409 # 2.5.4.9 (4) 343 6e # text(14) 344 3533322053204f6c697665205374 # "532 S Olive St" 345 a2 # map(2) 346 43 55040f # 2.5.4.15 (4) 347 6b # text(11) 348 5075626c6963205061726b # "Public Park" 349 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 350 6f # text(15) 351 5065727368696e6720537175617265 # "Pershing Square" 353 Figure 6: Distinguished Name, in CBOR (109 bytes) 355 (This example encoding assumes that all attribute values are UTF-8 356 strings, or can be represented as UTF-8 strings with no loss of 357 information.) 359 7. CDDL Control Operators 361 CDDL specifications may want to specify the use of SDNVs or SDNV 362 sequences (as defined for the tag content for TBD110). This document 363 introduces two new control operators that can be applied to a target 364 value that is a byte string: 366 * ".sdnv", with a control type that contains unsigned integers. The 367 byte string is specified to be encoded as an [RFC6256] SDNV (BER 368 encoding) for the matching values of the control type. 370 * ".sdnvseq", with a control type that contains arrays of unsigned 371 integers. The byte string is specified to be encoded as a 372 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 373 array of unsigned integers matching the control type. 375 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 376 structure using OIDs that could be used in Figure 6. 377 // We could define another control operator that includes the X*40+Y 378 // magic, so the example can actually use "[2, 5, 4, 6]". We could 379 // also add an operator that parses dotted decimal integer sequences, 380 // so we can use "2.5.4.6". I don't see a strong reason for that. 382 country-rdn = {country-oid => country-value} 383 country-oid = bytes .sdnvseq [85, 4, 6] 384 country-value = text .size 2 386 Figure 7: Using .sdnvseq 388 8. IANA Considerations 390 8.1. CBOR Tags 392 IANA is requested to assign the CBOR tags in Table 2, with the 393 present document as the specification reference. 395 +========+===========+============================================+ 396 | Tag | Data Item | Semantics | 397 +========+===========+============================================+ 398 | TBD111 | multiple | object identifier (BER encoding) | 399 +--------+-----------+--------------------------------------------+ 400 | TBD110 | multiple | relative object identifier (BER encoding); | 401 | | | SDNV [RFC6256] sequence | 402 +--------+-----------+--------------------------------------------+ 404 Table 2: Values for New Tags 406 8.2. CDDL Control Operators 408 IANA is requested to assign the CDDL Control Operators in Table 3, 409 with the present document as the specification reference. 411 +==========+============================+ 412 | Name | Reference | 413 +==========+============================+ 414 | .sdnv | [this document, Section 7] | 415 +----------+----------------------------+ 416 | .sdnvseq | [this document, Section 7] | 417 +----------+----------------------------+ 419 Table 3: New CDDL Operators 421 9. Security Considerations 423 The security considerations of RFC 7049 apply. 425 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 426 and unambiguous, but MUST be followed precisely to avoid security 427 pitfalls. In particular, the requirements set out in Section 2.1 of 428 this document need to be followed; otherwise, an attacker may be able 429 to subvert a checking process by submitting alternative 430 representations that are later taken as the original (or even 431 something else entirely) by another decoder supposed to be protected 432 by the checking process. 434 OIDs and relative OIDs can always be treated as opaque byte strings. 435 Actually understanding the structure that was used for generating 436 them is not necessary, and, except for checking the structure 437 requirements, it is strongly NOT RECOMMENDED to perform any 438 processing of this kind (e.g., converting into dotted notation and 439 back) unless absolutely necessary. If the OIDs are translated into 440 other representations, the usual security considerations for non- 441 trivial representation conversions apply; the primary integer values 442 are unlimited in range. 444 9.1. Conversions Between BER and Dotted Decimal Notation 446 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 447 well as for cases in which conversion to or from the dotted decimal 448 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 449 on the range of unsigned integer values for an arc; the integers are 450 arbitrarily valued. An implementation SHOULD NOT attempt to convert 451 each component using a fixed-size accumulator, as an attacker will 452 certainly be able to cause the accumulator to overflow. Compact and 453 efficient techniques for such conversions, such as the double dabble 454 algorithm [DOUBLEDABBLE] are well-known in the art; their application 455 to this field is left as an exercise to the reader. 457 10. References 458 10.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 466 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 467 2011, . 469 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 470 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 471 October 2013, . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 [X.660] International Telecommunications Union, "Information 478 technology -- Procedures for the operation of object 479 identifier registration authorities: General procedures 480 and top arcs of the international object identifier tree", 481 ITU-T Recommendation X.660, July 2011. 483 [X.680] International Telecommunications Union, "Information 484 technology -- Abstract Syntax Notation One (ASN.1): 485 Specification of basic notation", ITU-T Recommendation 486 X.680, August 2015. 488 [X.690] International Telecommunications Union, "Information 489 technology -- ASN.1 encoding rules: Specification of Basic 490 Encoding Rules (BER), Canonical Encoding Rules (CER) and 491 Distinguished Encoding Rules (DER)", ITU-T Recommendation 492 X.690, August 2015. 494 10.2. Informative References 496 [DOUBLEDABBLE] 497 Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD 498 adder using 6-LUT FPGAs", DOI 10.1109/newcas.2012.6328944, 499 10th IEEE International NEWCAS Conference, June 2012, 500 . 502 [OID-INFO] Orange SA, "OID Repository", 2016, 503 . 505 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 506 2018, . 508 [PKILCAKE] Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 509 Cake: New Collision Attacks against the Global X.509 510 Infrastructure", DOI 10.1007/978-3-642-14577-3_22, 511 Financial Cryptography and Data Security pp. 289-303, 512 2010, . 514 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 515 "Definition of Managed Objects for IPv6 over Low-Power 516 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 517 DOI 10.17487/RFC7388, October 2014, 518 . 520 [X.672] International Telecommunications Union, "Information 521 technology -- Open systems interconnection -- Object 522 identifier resolution system", ITU-T Recommendation X.672, 523 August 2010. 525 Appendix A. Change Log 527 This section is to be removed before publishing as an RFC. 529 A.1. Changes from -06 to -07 531 Reduce the draft back to its basic mandate: Describe CBOR tags for 532 what is colloquially know as ASN.1 Object IDs. 534 A.2. Changes from -05 to -06 536 Refreshed the draft to the current date ("keep-alive"). 538 A.3. Changes from -04 to -05 540 Discussed UUID usage in CBOR, and incorporated fixes proposed by 541 Olivier Dubuisson, including fixes regarding OID nomenclature. 543 A.4. Changes from -03 to -04 545 Changes occurred based on limited feedback, mainly centered around 546 the abstract and introduction, rather than substantive technical 547 changes. These changes include: 549 * Changed the title so that it is about tags and techniques. 551 * Rewrote the abstract to describe the content more accurately, and 552 to point out that no changes to the wire protocol are being 553 proposed. 555 * Removed "ASN.1" from "object identifiers", as OIDs are independent 556 of ASN.1. 558 * Rewrote the introduction to be more about the present text. 560 * Proposed a concise OID arc. 562 * Provided binary regular expression forms for OID validation. 564 * Updated IANA registration tables. 566 A.5. Changes from -02 to -03 568 Many significant changes occurred in this version. These changes 569 include: 571 * Expanded the draft scope to be a comprehensive CBOR update. 573 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 574 and Applications and Examples of OIDs. 576 * Added Tag 36 update (binary MIME, better definitions). 578 * Added stub/experimental sections for X.690 Series Tags (tag <>) 579 and Regular Expressions (tag 35). 581 * Added technique for representing sets and multisets. 583 * Added references and fixed typos. 585 Authors' Addresses 587 Carsten Bormann 588 Universität Bremen TZI 589 Postfach 330440 590 D-28359 Bremen 591 Germany 593 Phone: +49-421-218-63921 594 Email: cabo@tzi.org 595 Sean Leonard 596 Penango, Inc. 597 5900 Wilshire Boulevard 598 21st Floor 599 Los Angeles, CA, 90036 600 United States of America 602 Email: dev+ietf@seantek.com 603 URI: http://www.penango.com/