idnits 2.17.1 draft-ford-m2mcertificate-00.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 : ---------------------------------------------------------------------------- ** 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 227: '... -- Structure MUST be DER encoded...' RFC 2119 keyword, line 242: '...BJECT IDENTIFIER OPTIONAL, -- Identifi...' RFC 2119 keyword, line 251: '... cAAlgParams OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 257: '...suer Name OPTIONAL, -- Required...' RFC 2119 keyword, line 262: '... OCTET STRING (SIZE (4..5)) OPTIONAL,...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2015) is 3322 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: 'APPLICATION 20' is mentioned on line 230, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC4' -- Possible downref: Non-RFC (?) normative reference: ref. 'NFC-SIG' -- No information found for draft-ypoeluev-tls-m2m-certs - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft W. Ford 2 Intended status: Standards Track TrustPoint Innovation Technologies 3 Expires: September 2015 Y. Poeluev 4 TrustPoint Innovation Technologies 5 March 23, 2015 7 The Machine-to-Machine (M2M) Public Key Certificate Format 8 draft-ford-m2mcertificate-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 23, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 The X.509 public key certificate format is overly verbose for 48 Internet-of-Things (IoT) constrained environments, where nodes with 49 limited memory and networks with limited bandwidth are not uncommon. 50 The Machine-to-Machine (M2M) certificate format is a pruned down and 51 encoding-optimized replacement for X.509, which reuses much of the 52 X.509 semantics but reduces certificate sizes by typically 40%. We 53 are proposing that IETF recognize the M2M format as an optional 54 replacement for X.509 in Internet applications including, but not 55 limited to, TLS and DTLS. 57 Table of Contents 59 1. Introduction...................................................2 60 2. Restrictions Applied to the X.509 Model........................3 61 3. Other Optimizations............................................4 62 4. Certificate Size Estimates.....................................4 63 5. Certificate Format.............................................5 64 6. Rules for Omitting Algorithm Fields............................8 65 6.1. Algorithm Fields in CA Certificates.......................9 66 6.2. Algorithm Fields in End Entity Certificates...............9 67 7. Security Considerations........................................9 68 8. IANA Considerations............................................9 69 9. Conclusions....................................................9 70 10. References...................................................10 71 10.1. Normative References....................................10 72 10.2. Informative References..................................10 73 11. Acknowledgments..............................................10 74 Appendix A. Certificate Field Size Breakdown Tables..............11 75 A.1. EE Small Case............................................11 76 A.2. EE Medium Case...........................................12 77 A.3. CA Certificate Case......................................13 79 1. Introduction 81 The predominant public key certificate format has for many years been 82 the X.509 format [RFC5280]. X.509 was designed to be extremely 83 flexible and open-ended, in an environment of RSA and DSA signature 84 technologies. X.509 is not, however, a good certificate format for 85 Internet-of-Things constrained environments, where nodes with limited 86 memory and networks with limited bandwidth are not uncommon. With RSA 87 and DSA technologies, overheads in the certificate format were 88 comparatively inconsequential because the large key and signature 89 fields were the dominant certificate components size-wise. However, 90 with the much more efficient ECC technology used today, the 91 certificate format overheads become a very important factor in making 92 certificates efficient enough for low bandwidth constrained 93 applications. In essence, the X.509 certificate format is too 94 verbose for these applications. 96 There is a clear need for a more efficient certificate format than 97 X.509. Because many fields are inherently variable-length, it still 98 makes sense to use ASN.1 notation and encoding for this new format, 99 allowing us to borrow heavily from the X.509 model and to reuse much 100 of the X.509 semantics and some software. 102 The Machine-to-Machine (M2M) certificate format was designed to 103 satisfy the above objectives. What was done was to strip down the 104 X.509 format to eliminate features that are not needed today, while 105 optimizing the encoding. The result is a certificate format that 106 typically reduces certificate size by about 40% compared with X.509. 108 The M2M format supports various digital signature technologies 109 including ECDSA, RSA, and Elliptic Curve Qu-Vanstone (ECQV) [SEC4]. 110 No particular technology is required by this specification and we use 111 ECDSA as the baseline for comparative certificate size calculations. 113 The M2M certificate format has been adopted by the NFC Forum for Near 114 Field Communications signatures, and published by that organization 115 [NFC-SIG]. However it is a general purpose design which is equally 116 applicable to Internet-of-Things applications. 118 We are proposing that IETF recognize the M2M format as an optional 119 replacement for X.509 in Internet applications including, but not 120 limited to, TLS and DTLS. A companion Internet-Draft addresses the 121 use of the M2M format with TLS and DTLS [TLS-M2M]. 123 2. Restrictions Applied to the X.509 Model 125 The M2M certificate model restricts the X.509 model as follows: 127 o Directory Name (DN) names are limited to using the RFC 5280 128 mandatory attributes plus other attributes in common use, namely: 129 country, organization, organizational unit, distinguished name 130 qualifier, state or province name, common name, serial number, 131 locality, domain component. There can be only one of each, no 132 more than 4 total, and no multi-level names. M2M has also added 133 an Object Identifier (OID) option (may prove a useful identifier 134 for CAs) and an OCTET STRING option (may prove an efficient option 135 for device identifiers). 137 o DN character encodings are limited to one string type, usually 138 UTF8String (which a profile might limit to IA5 characters). 140 o Modest length constraints are defined for all DN attributes. 142 o Criticality flags for extensions are eliminated (criticality may 143 be implied by semantics). 145 o The following built-in extensions are defined for end-entity 146 certificates: issuer key id, subject key id, key usage (first 7 147 bits only), certificate policies (one OID, no qualifiers), subject 148 alternative name, issuer alternative name, extended key usage (one 149 OID), authority information access (URI for OCSP responder only). 151 o The following additional built-in extension is defined for CA- 152 certificates: basic constraints 154 o While it is not anticipated that applications will require 155 extensions other than the built-in extensions noted above, there 156 is a catch-all to optionally permit any standard X.509 extension 157 from RFC 5280 to be included. 159 3. Other Optimizations 161 An optional optimization known as "parameter inheritance" is also 162 provided. For applications where a certificate is always accompanied 163 in its transmission by its superior certificate, we can eliminate the 164 issuer field from the transmitted form of the certificate (it is 165 still included for signature generation and verification purposes). 166 Issuer name can be inherited from the subject field of the superior 167 certificate. Therefore, this field is made optional in the syntax in 168 order to allow two variants of every certificate: the full (to-be- 169 signed) form and the transmitted form. 171 In addition the M2M format adopts from SEC4 MES the use of Unix time 172 (rather than ASN.1 time types) to represent validity period. It also 173 drops the redundant algorithm identifier from the certificate outer 174 structure and makes sundry miscellaneous optimizations. 176 4. Certificate Size Estimates 178 Below are exemplary certificate size estimates for each of the 179 formats M2M and X.509 (we include SEC4 MES for the one case where it 180 applies). All sizes are for 224-bit ECC. We have used the following 181 example cases (note EE=end-entity certificate): 183 o EE Small case: ECDSA minimal data, one-component 8-character names 184 and 7-bit key usage extension. 186 o EE Medium case: ECDSA more general example, with two-component 16- 187 character names and these extensions: 7-bit key usage, certificate 188 policy OID, 20-character OCSP URL, 10-character subject alternate 189 name. 191 o CA Certificate case: A certificate for an ECDSA Sub-CA ECDSA- 192 signed by a root CA. Two-component 16-character names and 193 extensions: 7-bit key usage, basic constraints, 20-character OCSP 194 URL. 196 +-------------+-----------+----------+----------+ 197 | | M2M with | M2M | X.509 | 198 | | parameter | | | 199 | |inheritance| | | 200 +-------------+-----------+----------+----------+ 201 |EE Small | 136 | 155 | 241 | 202 |EE Medium | 189 | 218 | 364 | 203 |CA Cert | N/A | 207 | 338 | 204 +-------------+-----------+----------+----------+ 205 Figure 1 Certificate Sizes in Bytes 207 In summary, a standalone M2M EE certificate is roughly 140-to-220 208 bytes (compare 240-to-360 for X.509) and a two-certificate ECDSA 209 chain is roughly 340-to-420 bytes (compare 570-to-690 for X.509). 211 We assume Algorithm OIDs of the form 1.3.11111.1.1 (5 octets value 212 field) with no algorithm parameters and certificate serial numbers of 213 8 octets. 215 For more detail of the calculations leading to the above size 216 comparisons see Appendix A. 218 5. Certificate Format 220 The M2M certificate format is defined using Abstract Syntax Notation 221 One (ASN.1) [X.680]. 223 -- Machine-to-Machine certificate format 224 -- 225 M2M-Certificate-Definition 226 {1 3 186 asn1-modules (5) m2m-certificate (0)} 227 -- Structure MUST be DER encoded 228 DEFINITIONS AUTOMATIC TAGS ::= 229 BEGIN 230 Certificate ::= [APPLICATION 20] IMPLICIT SEQUENCE { 231 tbsCertificate TBSCertificate, -- To be signed certificate 232 cACalcValue OCTET STRING -- Contains signature for a signed 233 -- certificate or public key derivation value 234 -- for an ECQV certificate 235 } 236 -- The APPLICATION 20 tag is intended to make the M2M format 237 -- apparent by inspecting the first byte of the encoding 239 TBSCertificate ::= SEQUENCE { 240 version INTEGER {v1(0) } DEFAULT v1, 241 serialNumber OCTET STRING (SIZE (1..20)), 242 cAAlgorithm OBJECT IDENTIFIER OPTIONAL, -- Identifies CA 243 -- algorithm, hash function & optionally 244 -- other required parameters (e.g., for ECC the 245 -- curve). 246 -- Required for signature verification but may 247 -- be omitted from the transmitted cert and 248 -- filled in from the pKAlgorithm of the 249 -- superior cert (provided not root cert) 250 -- prior to signature verification 251 cAAlgParams OCTET STRING OPTIONAL, 252 -- Identifies CA algorithm parameters. 253 -- This specification does not provide for 254 -- omitting this field in transmission and 255 -- subsequently replacing it from the superior 256 -- certificate for signature verification 257 issuer Name OPTIONAL, -- Required for signature 258 -- verification but may be omitted from the 259 -- transmitted cert and filled in from the 260 -- subject field of the superior cert (provided 261 -- not root cert) prior to signature verification 262 validFrom OCTET STRING (SIZE (4..5)) OPTIONAL, 263 -- Unix time. If omitted no validity specified 264 validDuration OCTET STRING (SIZE (1..4)) OPTIONAL, 265 -- # of seconds. If omitted no expiry specified 266 subject Name, 267 pKAlgorithm OBJECT IDENTIFIER OPTIONAL, 268 -- Default is same as cAAlgorithm in this 269 -- certificate 271 pKAlgParams OCTET STRING OPTIONAL, 272 pubKey OCTET STRING OPTIONAL, -- Omit for an ECQV cert 273 authKeyId AuthKeyId OPTIONAL, 274 subjKeyId OCTET STRING OPTIONAL, 275 keyUsage OCTET STRING (SIZE (1)) OPTIONAL, -- Critical 276 -- One byte containing a bit string, as described below. 277 basicConstraints INTEGER (0..7) OPTIONAL, -- If absent this 278 -- is an end-entity cert; max intermed path length for CA cert 279 certificatePolicy OBJECT IDENTIFIER OPTIONAL, 280 subjectAltName GeneralName OPTIONAL, 281 issuerAltName GeneralName OPTIONAL, 282 extendedKeyUsage OBJECT IDENTIFIER OPTIONAL, 283 authInfoAccessOCSP IA5String OPTIONAL, -- OCSP responder URI 284 cRLDistribPointURI IA5String OPTIONAL, 285 -- CRL distribution point URI 286 x509extensions X509Extensions OPTIONAL, 287 ... 288 } 289 Name ::= SEQUENCE SIZE (1..4) OF AttributeValue 291 AttributeValue ::= CHOICE { 292 country PrintableString (SIZE (2)), 293 organization UTF8String (SIZE (1..32)), 294 organizationalUnit UTF8String (SIZE (1..32)), 295 distinguishedNameQualifier PrintableString (SIZE (1..32)), 296 stateOrProvince UTF8String (SIZE (1..4)), 297 locality UTF8String (SIZE (1..32)), 298 commonName UTF8String (SIZE (1..32)), 299 serialNumber PrintableString (SIZE (1..32)), 300 domainComponent IA5String (SIZE (1..32)), 301 registeredId OBJECT IDENTIFIER, 302 octetsName OCTET STRING (SIZE (1..8)) 303 } 304 AuthKeyId ::= SEQUENCE { 305 keyIdentifier OCTET STRING OPTIONAL, 306 authCertIssuer GeneralName OPTIONAL, 307 authCertSerialNum OCTET STRING (SIZE(1..20)) OPTIONAL 308 } 309 X509Extensions ::= SEQUENCE OF Extension 311 Extension ::= SEQUENCE { 312 extnID OBJECT IDENTIFIER, 313 criticality BOOLEAN DEFAULT FALSE, 314 extnValue OCTET STRING 315 } 316 GeneralName ::= CHOICE { 317 rfc822Name IA5String (SIZE (1..128)), 318 dNSName IA5String (SIZE (1..128)), 319 directoryName Name, 320 uniformResourceIdentifier IA5String (SIZE (1..128)), 321 iPAddress OCTET STRING (SIZE (1..16)), 322 --4 octets for IPV4, 16 octets for IPV6 323 registeredID OBJECT IDENTIFIER 324 } 325 -- Notes: 326 -- * The times are represented using Unix time, i.e. # of seconds 327 -- since the Unix epoch: http://en.wikipedia.org/wiki/Unix_time 328 -- The validFrom field permits 40-bit values to avoid problems in 329 -- 2038 (when 32-bit values won't be enough). 330 -- 331 -- The keyUsage field conveys a single octet equal to the 332 -- second octet of the DER encoding of the following BIT STRING 334 -- KeyUsage ::= BIT STRING { 335 -- digitalSignature (0), 336 -- nonRepudiation (1), 337 -- keyEncipherment (2), 338 -- dataEncipherment (3), 339 -- keyAgreement (4), 340 -- keyCertSign (5), 341 -- Use keyCertSign also for an ECQV certificate issuer 342 -- cRLSign (6) 343 -- the last bit in the byte is always zero (7) 344 END 346 6. Rules for Omitting Algorithm Fields 348 Following are the rules defining when and how omitting algorithm 349 fields is allowed. 351 6.1. Algorithm Fields in CA Certificates 353 cAAlgorithm: Omitting is only allowed when pKAlgorithm (or 354 cAAlgorithm if pKAlgorithm is omitted in a superior certificate) of a 355 superior certificate fully specifies the signature algorithm and its 356 parameters (i.e. signature and hash algorithms plus any required 357 parameters, e.g. in the case of ECC, the curve). 359 pKAlgorithm: If omitted in a CA certificate, cAAlgorithm specifies 360 the signature and hash algorithms and any required parameters (e.g. 361 curve) for pubKey Algorithm fields in End Entity Certificates. 363 6.2. Algorithm Fields in End Entity Certificates 365 cAAlgorithm: Omitting is only allowed when pKAlgorithm (or 366 cAAlgorithm if pKAlgorithm is omitted in a superior certificate) of a 367 superior certificate fully specifies the signature algorithm and its 368 parameters (i.e. signature and hash algorithms plus any required 369 parameters, e,g, in the case of ECC, the curve). 371 pKAlgorithm: If omitted in an end entity certificate, cAAlgorithm 372 specifies the required parameters (e.g. curve and optionally 373 signature & hash algorithms) for pubKey. 375 7. Security Considerations 377 The M2M Certificate Format is believed by the authors to have the 378 same security characteristics as the X.509 certificate format. 380 8. IANA Considerations 382 None known. 384 9. Conclusions 386 The IETF and applicable Working Groups are encouraged to adopt the 387 M2M certificate format as an optional alternative to the X.509 format 388 in all applications in the Internet-of-Things space. There are 389 significant size and bandwidth savings and no significant loss of 390 features of practical importance. 392 10. References 394 10.1. Normative References 396 [RFC5280] Cooper, D., et al, "Internet Public Key Infrastructure 397 Certificate and Certificate Revocation List (CRL) Profile", 398 RFC 5280, May 2008. 400 [SEC4] Standards for Efficient Cryptography Group (SECG), SEC 4: 401 Elliptic Curve Qu-Vanstone Implicit Certificates, January 402 2013. 404 [NFC-SIG] NFC Forum, Signature Record Type Definition, Technical 405 Specification, V2.0, 2014. http://nfc-forum.org/our- 406 work/specifications-and-application- 407 documents/specifications/nfc-forum-technical- 408 specifications/ 410 [X.690] ITU-T Recommendation X.690: ISO/IEC 8825-1:2002, 411 Information technology - ASN.1 encoding rules: 412 Specification of Basic Encoding Rules (BER), Canonical 413 Encoding Rules (CER) and Distinguished Encoding Rules 414 (DER), 2002. 416 10.2. Informative References 418 [TLS-M2M] Poeluev, Y., et al, "Transport Layer Security (TLS) and 419 Datagram Transport Layer Security (DTLS) Authentication 420 Using M2M Certificates", draft-ypoeluev-tls-m2m-certs- 421 00.txt (work in progress), February 2015. 423 11. Acknowledgments 425 Recognition is due to Rob Lambert and Jeremy Rowley for their 426 critical reviews of the specification, and to the development team of 427 TrustPoint Innovation Technologies for proving the specification 428 works in practical implementations. 430 This document was prepared using 2-Word-v2.0.template.dot. 432 Appendix A. Certificate Field Size Breakdown Tables 434 This Appendix lists the certificate field sizes used in arriving at 435 the certificate sizes in Figure 1. Use this to check our numbers and 436 also to see where M2M saves the bytes. 438 A.1. EE Small Case 440 +------------------------+-----------+----------+----------+ 441 | | M2M with | M2M | X.509 | 442 | | parameter | | | 443 | |inheritance| | | 444 +------------------------+-----------+----------+----------+ 445 |Basic envelope | 4 | 4 | 4 | 446 |Outside algorithm id | 0 | 0 | 9 | 447 |Outside algorithm params| 0 | 0 | 0 | 448 |Signature/CA calc value | 65 | 65 | 66 | 449 |Version | 0 | 0 | 5 | 450 |Serial number | 10 | 10 | 10 | 451 |Inside algorithm id | 0 | 7 | 9 | 452 |Algorithm parameters | 0 | 0 | 0 | 453 |Issuer | 0 | 12 | 23 | 454 |Validity | 11 | 11 | 32 | 455 |Subject | 12 | 12 | 23 | 456 |Subject algorithm | 0 | 0 | 11 | 457 |Subject parameters | 0 | 0 | 0 | 458 |Subject public key | 31 | 31 | 32 | 459 |Extensions envelope | 0 | 0 | 4 | 460 |Key usage 7-bit extn | 3 | 3 | 13 | 461 |Basic constraints extn | 0 | 0 | 0 | 462 |Cert policies extn | 0 | 0 | 0 | 463 |OCSP URL extn 20-char | 0 | 0 | 0 | 464 |Subject alt name 10-char| 0 | 0 | 0 | 465 |TOTAL | 136 | 155 | 241 | 466 +------------------------+-----------+----------+----------+ 468 Figure 2 EE Small Case Field Sizes in Bytes 470 A.2. EE Medium Case 472 +------------------------+-----------+----------+----------+ 473 | | M2M with | M2M | X.509 | 474 | | parameter | | | 475 | |inheritance| | | 476 +------------------------+-----------+----------+----------+ 477 |Basic envelope | 4 | 4 | 4 | 478 |Outside algorithm id | 0 | 0 | 9 | 479 |Outside algorithm params| 0 | 0 | 0 | 480 |Signature/CA calc value | 65 | 65 | 66 | 481 |Version | 0 | 0 | 5 | 482 |Serial number | 10 | 10 | 10 | 483 |Inside algorithm id | 0 | 7 | 9 | 484 |Algorithm parameters | 0 | 0 | 0 | 485 |Issuer | 0 | 22 | 42 | 486 |Validity | 11 | 11 | 32 | 487 |Subject | 22 | 22 | 42 | 488 |Subject algorithm | 0 | 0 | 11 | 489 |Subject parameters | 0 | 0 | 0 | 490 |Subject public key | 31 | 31 | 32 | 491 |Extensions envelope | 0 | 0 | 4 | 492 |Key usage 7-bit extn | 3 | 3 | 13 | 493 |Basic constraints extn | 0 | 0 | 0 | 494 |Cert policies extn | 7 | 7 | 20 | 495 |OCSP URL extn 20-char | 22 | 22 | 42 | 496 |Subject alt name 10-char| 14 | 14 | 23 | 497 |TOTAL | 189 | 218 | 364 | 498 +------------------------+-----------+----------+----------+ 500 Figure 3 EE Medium Case Field Sizes in Bytes 502 A.3. CA Certificate Case 504 +------------------------+-----------+----------+----------+ 505 | | M2M with | M2M | X.509 | 506 | | parameter | | | 507 | |inheritance| | | 508 +------------------------+-----------+----------+----------+ 509 |Basic envelope | N/A | 4 | 4 | 510 |Outside algorithm id | | 0 | 9 | 511 |Outside algorithm params| | 0 | 0 | 512 |Signature/CA calc value | | 65 | 66 | 513 |Version | | 0 | 5 | 514 |Serial number | | 10 | 10 | 515 |Inside algorithm id | | 7 | 9 | 516 |Algorithm parameters | | 0 | 0 | 517 |Issuer | | 22 | 42 | 518 |Validity | | 11 | 32 | 519 |Subject | | 22 | 42 | 520 |Subject algorithm | | 7 | 11 | 521 |Subject parameters | | 0 | 0 | 522 |Subject public key | | 31 | 32 | 523 |Extensions envelope | | 0 | 4 | 524 |Key usage 7-bit extn | | 3 | 13 | 525 |Basic constraints extn | | 3 | 17 | 526 |Cert policies extn | | 0 | 0 | 527 |OCSP URL extn 20-char | | 22 | 42 | 528 |Subject alt name 10-char| | 0 | 0 | 529 |TOTAL | | 207 | 338 | 530 +------------------------+-----------+----------+----------+ 532 Figure 4 CA Certificate Case Field Sizes in Bytes 534 Authors' Addresses 536 Warwick Ford 537 TrustPoint Innovation Technologies, Ltd. 538 700 S Monarch St Unit 203, 539 Aspen, CO 81611 541 Email: wford@wyltan.com 542 Yuri Poeluev 543 TrustPoint Innovation Technologies, Ltd. 544 450 Phillip St., Suite 101 545 Waterloo, ON, Canada, N2L 5J2 547 Email: ypoeluev@trustpointinnovation.com