idnits 2.17.1 draft-seantek-certspec-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 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 (October 21, 2013) is 3811 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SHS' is mentioned on line 214, but not defined == Missing Reference: 'RFC2397' is mentioned on line 237, but not defined == Missing Reference: 'RFC5652' is mentioned on line 276, but not defined == Missing Reference: 'RFC2253' is mentioned on line 291, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'CITE' is mentioned on line 400, but not defined == Missing Reference: 'MD5' is mentioned on line 476, but not defined == Unused Reference: 'RFC3406' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC4512' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'I-D.masinter-dated-uri' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC3187' is defined on line 553, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended status: Informational October 21, 2013 5 Expires: April 25, 2014 7 A Uniform Resource Name (URN) Namespace for Certificates 8 draft-seantek-certspec-01 10 Abstract 12 Digital certificates are used in many systems and protocols to 13 identify and authenticate parties. This document describes a Uniform 14 Resource Name (URN) namespace that identifies certificates. These 15 URNs can be used when certificates need to be identified by value or 16 reference. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Digital certificates are used in many systems and protocols to 53 identify and authenticate parties. Security considerations 54 frequently require that the certificate must be identified with 55 certainty, because selecting the wrong certificate will lead to 56 validation errors (resulting in denial of service), or in improper 57 credential selection (resulting in unwanted disclosure or 58 substitution attacks). The goal of this namespace is to provide a 59 uniform syntax for identifying certificates with precision in Uniform 60 Resource Identifiers (URIs), specifically Uniform Resource Names 61 (URNs). 63 Using this syntax, any protocol or system that refers to a 64 certificate in a textual format can unambiguously identify that 65 certificate by value or reference. Implementers that parse these 66 URNs can resolve them into actual certificates. 68 Examples: 69 urn:cert:SHA-1:3ea3f070773971539b9dbf1b98c54be3a4f0f3c8 70 urn:cert:issuersn:cn=AcmeIssuingCompany,st=California,c=US;0134F1 71 urn:cert:base64:MIICAS... 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. Motivation and Purpose 81 Although certificates have diverse applications, there has been 82 traditionally no way to refer to a certificate uniformly and 83 unambiguously by reference in text. Certificates that identify long 84 public keys (e.g., 2048-bit RSA keys) and that contain required and 85 recommended PKIX extensions can easily exceed many kilobytes in 86 length, which is impractical for certain applications. 88 The purpose of this specification is to provide a uniform textual 89 format for identifying individual certificates. When a resolver 90 resolves certspec, the resolver's output is either a single 91 certificiate or nothing. This specification is not designed or 92 intended to provide a search tool or query language to match multiple 93 certificates. 95 2.1. Static Identification 96 Identifying a specific certificate by reference or value allows 97 diverse applications to have a common syntax. For example, 98 applications can store certspecs as local or shared preferences, so 99 that users can edit them without resorting to application-specific 100 storage formats or relying on the availability of particular 101 protocols represented by URLs (such as http:, ldap:, file:, or ni: 102 schemes). When conveyed in protocol, a certspec can identify a 103 specific certificate to a client or server using text-based formats 104 such as YAML, XML, JSON, and others. The format described in this 105 document is intended to be readily reproducible by users using common 106 certificate processing tools, so that users can easily create, 107 recognize, compare, and reproduce them at a glance. For example, the 108 hash-based identifications use hexadecimal encoding so that a user 109 can easily compose or compare an URN with a simple copy-and-paste 110 operation. 112 2.2. Resolution to Context-Appropriate Schemes 114 When the certificate represented by a certspec needs to be resolved, 115 an application can resort to any number of schemes. For example, 116 when the certificate is identified by hash, the application can 117 resolve the cert: URN to a Named Information (ni:) URI [RFC6920] for 118 further processing. When the certificate is identified by issuer and 119 serial number, the application can resolve the cert: URN to an LDAP 120 service (for example, ldap:/// 121 cn=ExampleCA,o=ExampleCo,st=California,c=US ). 123 3. certspec Syntax 125 The Namespace Specific String (NSS) portion of a certspec has the 126 following ABNF specification: 128 NSS = spec-type ":" spec-value ( '?' certattrs) 129 spec-type = scheme 130 certattrs = 131 hexOctet = hexDigit hexDigit 132 hexDigit = 133 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / 134 "a" / "b" / "c" / "d" / "e" / "f" / 135 "A" / "B" / "C" / "D" / "E" / "F" 137 3.1. spec-type and spec-value 139 The spec-type identifies the certificate specification type. The 140 acceptable characters for spec-type are the same as an URI scheme 141 name [RFC3986 sec. 3.1]. spec-types are compared case-insensitively. 142 The spec-value identifies the certificate specification value. The 143 acceptable characters for spec-value depend on the spec-type. 145 3.2. certattrs 147 A certspec can include attributes that are associated with the 148 identified certificate. These attributes do NOT affect certificate 149 identification; the syntax is intended primarily to convey 150 certificate metadata such as attributes found in PKCS #9, PKCS #11, 151 PKCS #12, and particular implementations of cryptographic libraries. 152 This Internet-Draft does not further define certattrs; the characters 153 of certattrs can be any valid URN character from [RFC2141] 154 (effectively, any URI character from [RFC3986] except [ and ]). 156 4. Certificate Specifications 158 A certificate specification (certspec) unambiguously identifies a 159 single certificate. However, multiple certspecs may exist for a 160 particular certificate. This Internet-Draft provides five 161 cryptographic hash-based specs, two value-based specs, and two data- 162 based specs. 164 4.1. Cryptographic Hash-Based Specifications 166 A cryptographic hash of a certificate uniquely identifies that 167 certificate. Such a hash may also be called a "certificate 168 fingerprint". In all certspecs in this specification *or* derived 169 from this specification, the hash is computed over the octets of the 170 DER encoding of the certificate, namely, the Certificate type of 171 [RFC5280 sec. 4.1]. The DER encoding includes tag and length octets, 172 so it always starts with 30h (the tag for SEQUENCE). 174 In certspecs in this specification, the spec-value is the hexadecimal 175 encoding of the hash value octets. For example, a 256-bit SHA-256 176 hash is represented by exactly 32 hex octets, or 64 hex characters. 177 The following ABNF defines proper spec-values: 179 spec-value-sha-1 = 20hexOctet 180 spec-value-sha-256 = 32hexOctet 181 spec-value-SHA-384 = 48hexOctet 182 spec-value-SHA-512 = 64hexOctet 183 Lexical equivalence of two certspecs that have the same spec-type 184 SHALL be determined by a case-insensitive comparison of spec-values, 185 or by converting the hexadecimal spec-values to octets and comparing 186 exact equivalence of the octets. A conforming implementation MUST 187 reject values that contain non-hex digits, such as spaces, tabs, 188 hyphens, or anything else. 190 Conforming implementations to this Internet-Draft MUST process these 191 hash-based certspecs, unless security considerations dictate 192 otherwise. Acceptable reasons for refusing to process a certspec 193 include a) the local policy prohibits use of the hash, or b) the hash 194 has known cryptographic weaknesses, such as a preimage attacks, which 195 weaken the cryptographic uniqueness guarantees of the hash. 197 4.1.1. SHA-1 199 The spec-type is "SHA-1". The hash is computed using SHA-1 [SHS]. 201 4.1.2. SHA-256 203 The spec-type is "SHA-256". The hash is computed using SHA-256 204 [SHS]. 206 4.1.3. SHA-384 208 The spec-type is "SHA-384". The hash is computed using SHA-384 209 [SHS]. 211 4.1.4. SHA-512 213 The spec-type is "SHA-512". The hash is computed using SHA-512 214 [SHS]. 216 4.2. Value-Based Specifications 218 A certificate may be identified reflexively by its constituent 219 octets. For small-to-medium certificates, identifying the 220 certificate by embedding it in the certspec will be computationally 221 efficient and resistant to denial-of-service attacks (by being always 222 available). A conforming implementation MUST implement base64 and 223 hex specs. 225 The octets of a certificate are the octets of the DER encoding of the 226 certificate, namely, the Certificate type of [RFC 5280 sec. 4.1]. 228 Lexical equivalence of two certspecs that are value-based SHALL be 229 determined by converting the spec-value to certificate octets, and 230 comparing the octets for strict equivalence. Accordingly, it is 231 possible that base64 and hex certspecs are lexically equivalent. 233 4.2.1. base64 235 The spec-type is "base64". The spec-value is the base64 encoding 236 [RFC4648 sec. 4] of the certificate octets. Like the data: URL 237 [RFC2397], the characters '+' and '/' refer to values 62 and 63, 238 respectively. Additionally, if the length of certificate octets is 239 not a multiple of 3, it is expected that one or two trailing equal 240 signs '=' will be present. 242 '+', '/', and '=' have no reserved meaning in this spec-type. While 243 the URN syntax rules [RFC2141] state that '/' should not be used in 244 unencoded form, in this specification, '/' MAY be present in 245 unencoded form in the base64 spec-type. In any case, a conforming 246 implementation MUST be able to process "%"-encoded characters. 248 While a strict implementation would reject non-base64 characters, a 249 lenient implementation MAY ignore non-base64 characters, such as CR, 250 LF, whitespace, or the absence of trailing '='. As a result, two 251 certspecs that have the same base64-encoded data but different stray 252 non-base64 characters MAY be judged lexically equivalent. Similarly, 253 [RFC2141] requires that non-reserved characters (in this case, 254 alphanumerics) must not be "%"-encoded, but a lenient implementation 255 MAY decode these "%"-encoded characters anyway. This specification 256 neither recommends nor discourages such leniency, but implementors 257 should weigh the benefits and risks as discussed further in the 258 Security Considerations section [TODO: link]. 260 4.2.2. hex 262 The spec-type is "hex". The spec-value is the hexadecimal encoding 263 [RFC4648 sec. 8] of the certificate octets. Whether an 264 implementation should process "%"-encoded characters is subject to 265 the same considerations as the equivalent characters in the base64 266 spec. 268 4.2.3. data (Reserved) 270 The spec-type is "data". This type SHOULD NOT be used for 271 interchange. This document reserves this spec-type for future use. 273 4.3. Data-Based Specifications 274 A certificate may be identified by data contained within it. The 275 following specs reflect the traditional reliance of PKIX [RFC5280] 276 and CMS [RFC5652] on a certificate's issuer distinguished name and 277 serial number, or a certificate's subject key identifier. These 278 specs provide textual representations for these identifiers. 280 4.3.1. issuersn: Issuer Name and Serial Number 282 The spec-type is "issuersn". The spec-value is given by the 283 following ABNF: 285 spec-value-issuersn = distinguishedName SEMI serialNumber 286 serialNumber = 1*hexOctet 288 is defined in [RFC4514], and is defined in 289 RFC4512. Note that RFC 4514 no longer separates relative 290 distinguished names (RDNs) by semicolons, as required by its 291 predecessor, [RFC2253]. Accordingly, ';' is used to separate the 292 issuer's DN from the subject's serial number. 294 Care should be taken in escaping and "%"-encoding the relevant 295 characters. In particular: "?" is permitted in a distinguishedName, 296 but is RESERVED by this specification and [RFC2141]. Any question 297 marks in distinguished names MUST be "%"-encoded when placed in the 298 spec-value. "#" is used as a token at the beginning of the hexstring 299 production for attributeValue data, but is RESERVED by [RFC2141]. 300 The updated draft draft-ietf-urnbis-rfc2141bis-urn clarifies that "#" 301 denotes the beginning of the fragment identifier component, and 302 therefore can be used after (not within) the Namespace Specific 303 String. Any "#" characters in distinguished names MUST be 304 "%"-encoded when placed in the spec-value. 306 is the hexadecimal encoding of the certificate's 307 serial number, with the exact same (DER encoded) contents octets of a 308 CertificateSerialNumber ::= INTEGER as specified in [RFC5280] sec. 309 4.1. If the serial number hex octets are malformed, the certspec is 310 invalid. 312 A conforming implementation SHOULD implement this issuersn spec. If 313 the implementation implements it, the implementation MUST process 314 serial numbers up to the same length as required by [RFC5280] sec. 315 4.1.2.2 (20 octets), and MUST process distinguished name strings as 316 required by [RFC4514], including the table of minimum AttributeType 317 name strings that MUST be recognized. 319 Lexical equivalence of two issuersn certspecs SHALL be determined by 320 comparing the integer values of the serialNumbers for exact 321 equivalence, and comparing the distinguished names for a match. 322 Distinguished names match if they satisfy the name matching 323 requirements of [RFC5280]. 325 4.3.2. ski: Subject Key Identifier) 327 The spec-type is "ski". The spec-value is given by the following 328 ABNF: 330 spec-value-ski = keyIdentifier 331 keyIdentifier = 1*hexOctet 333 is the hexadecimal encoding of the certificate's 334 subject key identifier, which is recorded in the certificate's 335 Subject Key Identifier extension [RFC5280] sec. 4.2.1.2. A 336 certificate that lacks a subject key identifier cannot be identified 337 using this spec. 339 Lexical equivalence of two ski certspecs SHALL be determined by 340 converting the hexadecimal spec-values to octets and comparing the 341 exact equivalence of the octets. 343 A conforming implementation MAY implement this ski spec. 345 4.3.3. dbkey (Reserved) 347 The spec-type is "dbkey". This type SHOULD NOT be used for 348 interchange. This document reserves this spec-type for future use. 350 5. Registration Template 352 Namespace ID: 353 cert 355 Registration Information: 356 Version: 1 357 Date: 2013-10-21 359 Declared registrant of the namespace: 360 IETF 362 Declaration of syntactic structures: 363 The structure of the Namespace Specific String is provided 364 above. 366 Relevant ancillary documentation: 367 Certificates are defined by [RFC5280] and [X.509]. 369 Identifier uniqueness considerations: 370 The spec type is assigned by IANA through the IETF consensus 371 process, so this process guarantees uniqueness of these 372 identifiers. The uniqueness of the spec value depends on the 373 spec type. For specs that identify cryptographic hashes, the 374 cryptographic hash algorithm itself guarantees uniquess. 375 For specs that identify certificates by value, the inclusion 376 of the certificate in the URN itself guarantees uniqueness. 377 For specs that identify certificates by certificate data, 378 the resolver's database of certificates and implementation 379 of certification path validation [RFC5280 sec. 6] ensure 380 uniqueness. 382 Identifier persistence considerations: 383 A certificate is a permanent digital artifact, irrespective of 384 its origin. As the assignment process records mathematical or 385 existential facts about the certificate, such as one of its 386 cryptographic hashes, the binding between the URN and 387 the certificate resource is permanent. Changing even one bit 388 of the certificate will alter its URN, will make the 389 certificate unresolvable, or both. 391 Process of identifiers assignment: 392 Generating a certspec (cert URN) does not require that 393 a registration authority be contacted. 395 Process for identifier resolution: 396 This Internet Draft does not specify a resolution service 397 for certspecs. However, resolving certificate references 398 to actual certificates is a common practice with a wide number 399 of offline and online implementations. 400 [CITE][CITE][CITE][CITE] 402 Rules for Lexical Equivalence: 403 Certspecs (cert URNs) are lexically equivalent if they both 404 have the same spec type (compared case-insensitively) 405 and the same space value, and therefore impliedly point 406 to the same certificate. 407 Comparison of spec values depends on the rules of the spec. 408 Although extensions may be appended to a certspec, 409 these extensions are guaranteed not to affect lexical 410 equivalence. 412 Certspecs are semantically equivalent if they both resolve 413 to the same certificate. 415 Conformance with URN Syntax: 416 The character '?' is reserved for future extensions to this 417 specification. The URN of this namespace conforms to URN Syntax 418 [RFC2141] and Uniform Resource Identifier (URI): Generic Syntax 419 [RFC3986]. 421 Validation mechanism: 422 Each spec defines the validation mechanism for its respective 423 value. It may be appreciated that validation of the URN is a 424 completely different process from the Certification Path 425 Validation Algorithm [RFC5280 sec. 6], which determines whether 426 the *certificate* is valid. 428 Scope: 429 Global. 431 6. Use of certspec outside URN 433 certspec is useful wherever a system may need to refer to a 434 certificate by value or by reference. Some implementations may wish 435 to refer to a certificate without enabling all of the expressive 436 power (and security considerations) of URIs. Accordingly, this 437 section provides a uniform method for using a certspec outside of a 438 URN. Examples: 440 Examples: 441 SHA-1:aaaaaaaaaaa 442 WHIRLPOOL:aaaaaaaaaaaaaa 443 base64:MIICAS... 445 To use certspec outside of a URI (URN) context, simply omit the 446 prefix "urn:cert:". All other lexical rules remain in effect, 447 including "%"-encoding. Care should be taken to process '?' in 448 particular, since '?' separates the certspec from appended 449 attributes. A conforming implementation of raw certspecs MUST permit 450 the prefix "urn:cert:" in addition to the raw certspec, which starts 451 with the spec-type. This specification guarantees that the the cert- 452 type "urn" is RESERVED and will never be used. However, implementors 453 must take note that a raw certspec is not a valid URI, because cert- 454 types are not registered URI schemes and do not have the same 455 semantics as a URI. 457 7. IANA Considerations 459 This document requests the assignment of formal URN namespace ID 460 "cert". 462 This document requests the creation of a registry to record specs. 463 New specs shall be ratified by the IETF consensus process. 465 8. Security Considerations 467 Digital certificates are important building blocks for 468 authentication, integrity, authorization, and (occasionally) 469 confidentiality services. Accordingly, identifying digital 470 certificates incorrectly can have significant security ramifications. 472 When using specs that are cryptographic hashes (fingerprints), the 473 cryptographic hash algorithm MUST be implemented properly and SHOULD 474 have no known attack vectors. For this reason, algorithms that are 475 considered "broken" as of the date of this Internet-Draft, such as 476 MD5 [MD5], are precluded from being valid certspecs. The 477 registration of a particular algorithm spec in this namespace does 478 NOT mean that it is acceptable or safe for every usage, even though 479 this Internet-Draft requires that a conforming implementation MUST 480 implement certain specs. 482 When using by-value specs, the implementation MUST be prepared to 483 process URNs of arbitrary length. As of this writing, useful 484 certificates rarely exceed 10KB, and most implementations are 485 concerned with keeping certificate sizes down rather than up [CITE: 486 Google SSL overclocking, etc.]. However, a pathological or malicious 487 certificate could easily exceed these metrics. If an URN resolver 488 cannot process a URN's full length, it MUST reject the certspec. 490 When using specs that depend on certificate data, the implementation 491 MUST be prepared to deal with multiple found certificates that 492 contain the same certificate data, but are not the same certificate. 493 In such a case, the implementation MUST segregate these certificates 494 so that it only resolves the URN to certificates that it considers 495 valid or trustworthy (as discussed further below). If, despite this 496 segregation, multiple valid or trustworthy certificates match the 497 certspec, the certspec MUST be rejected, because a certspec is meant 498 to identify exactly one certificate (not a family of certificates). 500 Apart from the mechanics of certspecs (cert URNs), certificates 501 should not be used unless they have passed the Certification Path 502 Validation Algorithm [RFC5280 sec. 6], or another algorithm that 503 provides some guarantee of validity. For example, if a certificate 504 database contains a set of certificates that it considers inherently 505 trustworthy, then the inclusion of a certificate in that set makes it 506 trustworthy, regardless of the results of the Certification Path 507 Validation Algorithm. Such a database is frequently used for "Root 508 CA" lists. 510 9. References 512 9.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 519 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 520 "Uniform Resource Names (URN) Namespace Definition 521 Mechanisms", BCP 66, RFC 3406, October 2002. 523 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 524 Resource Identifier (URI): Generic Syntax", STD 66, RFC 525 3986, January 2005. 527 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 528 (LDAP): Directory Information Models", RFC 4512, June 529 2006. 531 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 532 (LDAP): String Representation of Distinguished Names", RFC 533 4514, June 2006. 535 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 536 Housley, R., and W. Polk, "Internet X.509 Public Key 537 Infrastructure Certificate and Certificate Revocation List 538 (CRL) Profile", RFC 5280, May 2008. 540 9.2. Informative References 542 [I-D.masinter-dated-uri] 543 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on 544 dated URIs", draft-masinter-dated-uri-10 (work in 545 progress), January 2012. 547 [ISO.8601.1988] 548 International Organization for Standardization, "Data 549 elements and interchange formats - Information interchange 550 - Representation of dates and times", ISO Standard 8601, 551 June 1988. 553 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 554 Book Numbers as Uniform Resource Names", RFC 3187, October 555 2001. 557 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 558 Keranen, A., and P. Hallam-Baker, "Naming Things with 559 Hashes", RFC 6920, April 2013. 561 Author's Address 563 Sean Leonard 564 Penango, Inc. 565 11400 West Olympic Boulevard 566 Suite 1500 567 Los Angeles, CA 90064 568 USA 570 Email: dev+ietf@seantek.com 571 URI: http://www.penango.com/