idnits 2.17.1 draft-ietf-acme-email-smime-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2020) is 1256 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 375, but not defined ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational November 17, 2020 5 Expires: May 21, 2021 7 Extensions to Automatic Certificate Management Environment for end-user 8 S/MIME certificates 9 draft-ietf-acme-email-smime-11 11 Abstract 13 This document specifies identifiers and challenges required to enable 14 the Automated Certificate Management Environment (ACME) to issue 15 certificates for use by email users that want to use S/MIME. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 21, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. Use of ACME for issuing end-user S/MIME certificates . . . . 3 54 3.1. ACME challenge email . . . . . . . . . . . . . . . . . . 4 55 3.2. ACME response email . . . . . . . . . . . . . . . . . . . 6 56 4. Internationalization Considerations . . . . . . . . . . . . . 8 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 8 59 5.2. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 63 7.2. Informative References . . . . . . . . . . . . . . . . . 12 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 67 1. Introduction 69 ACME [RFC8555] is a mechanism for automating certificate management 70 on the Internet. It enables administrative entities to prove 71 effective control over resources like domain names, and automates the 72 process of generating and issuing certificates. 74 This document describes an extension to ACME for use by S/MIME. 75 Section 3 defines extensions for issuing end-user S/MIME [RFC8550] 76 certificates. 78 This document aims to support both: 80 1. A Mail User Agent (MUA) which has built in ACME client aware of 81 the extension described in this document. (We will call such 82 ACME clients "ACME-email-aware") Such MUA can present nice User 83 Interface to the user and automate certificate issuance. 85 2. A MUA which is not ACME aware, with a separate ACME client 86 implemented in a command line tool or as a part of a website. 87 While S/MIME certificate issuance is not going to be as painless 88 as in the case of the ACME-email-aware MUA, the extra burden on a 89 user is going to be minimal. 91 2. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Use of ACME for issuing end-user S/MIME certificates 99 ACME [RFC8555] defines a "dns" Identifier Type that is used to verify 100 that a particular entity has control over a domain or specific 101 service associated with the domain. In order to be able to issue 102 end-user S/MIME certificates, ACME needs a new Identifier Type that 103 proves ownership of an email address. 105 This document defines a new Identifier Type "email" which corresponds 106 to an email address. The address can be all ASCII [RFC5321] or 107 internationalized [RFC6531]; when an internationalized email address 108 is used, the domain part can contain both U-labels and A-labels 109 [RFC5890]. This can be used with S/MIME or other similar service 110 that requires possession of a certificate tied to an email address. 112 Any identifier of type "email" in a newOrder request MUST NOT have a 113 wildcard ("*") character in its value. 115 A new challenge type "email-reply-00" is used with "email" Identifier 116 Type, which provides proof that an ACME client has control over an 117 email address. 119 The process of issing an S/MIME certificate works as follows. Note 120 that the ACME client can be a standalone application (if the MUA is 121 not ACME-email-aware) or can be a component of the MUA. 123 1. An end-user initiates issuance of an S/MIME certificate for one 124 of her email addresses. This might be done using email client 125 UI, by running a command line tool, by visiting a Certificate 126 Authority web page, etc. This document doesn't prescribe 127 specific UI used to initiate S/MIME certificate issuance or where 128 the ACME client is located. 130 2. The ACME-email-aware client component begins the certificate 131 issuance process by sending a POST request to the server's 132 newOrder resource, including the identifier of type "email". See 133 Section 7.4 of [RFC8555] for more details. 135 3. The ACME server responds to the POST request, including an 136 "authorizations" URL for the requested email address. The ACME 137 client then retrieves information about the corresponding "email- 138 reply-00" challenge as specified in Section 7.5 of [RFC8555]. 139 The "token" field of the corresponding "challenges" array element 140 (which contains "type": "email-reply-00" as another field) 141 contains token-part2. token-part2 should contain at least 128 142 bits of entropy. 144 4. After responding to the authorization request the ACME server 145 generates another token and a "challenge" email message with the 146 subject "ACME: ", where is the 147 base64url encoded [RFC4648] form of the token. The ACME server 148 MUST generate a fresh token for each S/MIME issuance request 149 (authorization request), and token-part1 MUST contain at least 150 128 bits of entropy. The challenge email message structure is 151 described in more details in Section 3.1. 153 5. The MUA retrieves and parses the challenge email message. The 154 ACME client concatenates "token-part1" (received over email) and 155 "token-part2" (received over HTTPS [RFC2818]) to create the ACME 156 "token", calculates keyAuthorization (as per Section 8.1 of 157 [RFC8555]), then returns the base64url encoded SHA-256 digest 158 [FIPS180-4] of the key authorization. The MUA returns the 159 base64url encoded SHA-256 digest obtained from the ACME client in 160 the body of a response email message. The response email message 161 structure is described in more details in Section 3.2. 163 6. Once the MUA sends the response email, the ACME client can start 164 polling the authorization URL (using POST-as-GET requests) to see 165 if the ACME server received and validated the response email 166 message. (See Section 7.5.1 of [RFC8555] for more details.) If 167 the "status" field of the challenge switches to "valid", then the 168 ACME client can proceed with request finalization. The 169 Certificate Signing Request (CSR) MUST indicate the exact same 170 set of requested identifiers as the initial newOrder request. 171 For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST 172 contain the requested email address in an extensionRequest 173 attribute [RFC2985] requesting a subjectAltName extension. If a 174 request to finalize an order is successful, the ACME server will 175 return a 200 (OK) with an updated order object. If the 176 certificate is issued successfully, i.e. if the order "status" is 177 "valid", then the ACME client can download the issued S/MIME 178 certificate from the URL specified in the "certificate" field. 180 3.1. ACME challenge email 182 A "challenge" email message MUST have the following structure: 184 1. The message Subject header field has the following syntax: "ACME: 185 ", where the prefix "ACME:" is followed by folding 186 white space (FWS, see [RFC5322]) and then by , which 187 is the base64url encoded first part of the ACME token that MUST 188 be at least 128 bits long after decoding. Due to the recommended 189 78-octet line length limit in [RFC5322], the subject line can be 190 folded, so whitespaces (if any) within the MUST be 191 ignored. [RFC2231] encoding of the message Subject header field 192 MUST be supported, and when used, only the "UTF-8" and "US-ASCII" 193 charsets are allowed: other charsets MUST NOT be used. US-ASCII 194 charset SHOULD be used. 196 2. The To header field MUST be the email address of the entity that 197 requested the S/MIME certificate to be generated. 199 3. The message MAY contain a Reply-To header field. 201 4. The message MUST include the "Auto-Submitted: auto-generated" 202 header field [RFC3834]. To aid in debugging (and in for some 203 implementations to make automated processing easier) the "Auto- 204 Submitted" header field SHOULD include the "type=acme" parameter. 205 It MAY include other optional parameters as allowed by the syntax 206 of the Auto-Submitted header field. 208 5. In order to prove authenticity of a challenge message, it MUST be 209 signed using either DKIM [RFC6376] or S/MIME [RFC8551]. 211 If DKIM signing is used, the resulting DKIM-Signature header 212 field MUST contain the "h=" tag that includes at least "From", 213 "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In- 214 Reply-To", "References", "Message-ID", "Auto-Submitted", 215 "Content-Type", and "Content-Transfer-Encoding" header fields. 216 The domain from the "d=" tag of DKIM-Signature header field 217 MUST be the same as the domain from the From header field of 218 the challenge email. 220 If S/MIME signing is used, the certificate corresponding to 221 the signer MUST have rfc822Name subjectAltName extension with 222 the value equal to the From header field email address of the 223 challenge email. 225 6. The body of the challenge message is not used for automated 226 processing, so it can be any media type. (However there are 227 extra requirements on S/MIME signing, if used. See below.) 228 Typically it is text/plain or text/html containing a human- 229 readable explanation of the purpose of the message. If S/MIME 230 signing is used to prove authenticity of the challenge message, 231 then the multipart/signed or "application/pkcs7-mime; smime- 232 type=signed-data;" media type should be used. Either way, it 233 MUST use S/MIME header protection. 235 An email client compliant with this specification that detects that a 236 particular challenge email fails validation described above MUST 237 ignore the challenge and thus will not generate any response email. 238 To aid in debugging such failed validations SHOULD be logged. 240 An example ACME "challenge" email (note that for simplicity DKIM 241 related header fields are not included). 243 Auto-Submitted: auto-generated; type=acme 244 Date: Sat, 5 Dec 2020 10:08:55 +0100 245 Message-ID: 246 From: acme-generator@example.org 247 To: alexey@example.com 248 Subject: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= 249 Content-Type: text/plain 250 MIME-Version: 1.0 252 This is an automatically generated ACME challenge for email address 253 "alexey@example.com". If you haven't requested an S/MIME 254 certificate generation for this email address, be very afraid. 255 If you did request it, your email client might be able to process 256 this request automatically, or you might have to paste the first 257 token part into an external program. 259 Figure 1 261 3.2. ACME response email 263 A valid "response" email message MUST have the following structure: 265 1. The message Subject header field is formed as a reply to the ACME 266 challenge email (see Section 3.1). Its syntax is the same as 267 that of the challenge message except that it may be prefixed by a 268 US-ASCII reply prefix (typically "Re:") and folding white space 269 (FWS, see [RFC5322]), as is normal in reply messages. When 270 parsing the subject, ACME servers MUST decode [RFC2231] encoding 271 (if any) and then they can ignore any prefix before the "ACME:" 272 label. 274 2. The From: header field contains the email address of the user 275 that is requesting S/MIME certificate issuance. 277 3. The To: header field of the response contains the value from the 278 Reply-To: header field from the challenge message (if set) or 279 from the From: header field of the challenge message otherwise. 281 4. The Cc: header field is ignored if present in the "response" 282 email message. 284 5. The In-Reply-To: header field SHOULD be set to the Message-ID 285 header field of the challenge message according to rules in 286 Section 3.6.4 of [RFC5322]. 288 6. List-* header fields [RFC4021][RFC8058] MUST be absent (i.e., the 289 reply can't come from a mailing list) 291 7. The media type of the "response" email message is either text/ 292 plain or multipart/alternative [RFC2046] containing text/plain as 293 one of the alternatives. (Note that the requirement to support 294 multipart/alternative is to allow use of ACME-unaware MUAs which 295 can't always generate pure text/plain, e.g. if they reply to a 296 text/html). The text/plain body part (whether or not it is 297 inside multipart/alternative) MUST contain a block of lines 298 starting with the line "-----BEGIN ACME RESPONSE-----", followed 299 by one or more line containing the base64url-encoded SHA-256 300 digest [FIPS180-4] of the key authorization, calculated from 301 concatenated token-part1 (received over email) and token-part2 302 (received over HTTPS), as outlined in the 5th bullet in 303 Section 3. (Note that each line of text/plain is terminated by 304 CRLF. Bare LFs or bare CRs are not allowed.) Due to historical 305 line length limitations in email, line endings (CRLFs) can be 306 freely inserted in the middle of the encoded digest, so they MUST 307 be ignored when processing it.) The final line of the encoded 308 digest is followed by a line containing "-----END ACME 309 RESPONSE-----". Any text before and after this block is ignored. 310 For example such text might explain what to do with it for ACME- 311 unaware clients. 313 8. There is no need to use any Content-Transfer-Encoding other than 314 7bit for the text/plain body part. Use of Quoted-Printable or 315 base64 in a "response" email message is not necessary and should 316 be avoided, though it is permitted. 318 9. In order to prove authenticity of a response message, it MUST be 319 DKIM [RFC6376] signed. The resulting DKIM-Signature header field 320 MUST contain the "h=" tag that includes at least "From", 321 "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply- 322 To", "References", "Message-ID", "Content-Type", and "Content- 323 Transfer-Encoding" header fields. The domain from the "d=" tag 324 of DKIM-Signature header field MUST be the same as the domain 325 from the From header field of the response email. 327 Example ACME "response" email (note that for simplicity DKIM related 328 header fields are not included). 330 Date: Sat, 5 Dec 2020 12:01:45 +0100 331 Message-ID: <111-22222-3333333@example.com> 332 In-Reply-To: 333 From: alexey@example.com 334 To: acme-generator@example.org 335 Subject: Re: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= 336 Content-Type: text/plain 337 MIME-Version: 1.0 339 -----BEGIN ACME RESPONSE----- 340 LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy 341 jxAjEuX0= 342 -----END ACME RESPONSE----- 344 Figure 2 346 4. Internationalization Considerations 348 [RFC8616] updated/clarified use of DKIM with Internationalized Email 349 addresses [RFC6531]. Please consult RFC 8616 in regards to any 350 changes that need to be implemented. 352 Use of non ASCII characters in left hand sides of Internationalized 353 Email addresses requires putting Internationalized Email Addresses in 354 X.509 Certificates [RFC8398]. 356 5. IANA Considerations 358 5.1. ACME Identifier Type 360 IANA is requested to register a new Identifier type in the "ACME 361 Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with 362 Label "email" and a Reference to [RFCXXXX], [RFC5321] and [RFC6531]. 363 The new Identifier Type corresponds to an (all ASCII) email address 364 [RFC5321] or Internationalized Email addresses [RFC6531]. 366 5.2. ACME Challenge Type 368 IANA is also requested to register a new entry in the "ACME 369 Validation Methods" registry defined in Section 9.7.8 of [RFC8555]. 370 This entry is as follows: 372 +----------------+-----------------+------+-----------+ 373 | Label | Identifier Type | ACME | Reference | 374 +----------------+-----------------+------+-----------+ 375 | email-reply-00 | email | Y | [RFCXXXX] | 376 +----------------+-----------------+------+-----------+ 378 6. Security Considerations 380 Please see Security Considerations of [RFC8555] for general security 381 considerations related to use of ACME. This challenge/response 382 protocol demonstrates that an entity that controls the private key 383 (corresponding to the public key in the certificate) also controls 384 the named email account. The ACME server is confirming that the 385 requested email address belongs to the entity that requested the 386 certificate, but this makes no claim to correctness or fitness-for- 387 purpose of the address. It such claims are needed they must be 388 obtained by some other mechanism. 390 The security of the "email-reply-00" challenge type depends on the 391 security of the email system. A third party that can read and reply 392 to user's email messages (by possessing a user's password or a secret 393 derived from it that can give read and reply access, such as 394 "password equivalent" information; or by being given permissions to 395 act on a user's behalf using email delegation feature common in some 396 email systems) can request S/MIME certificates using the protocol 397 specified in this document and is indistinguishable from the email 398 account owner. This has several possible implications: 400 1. an entity that compromised an email account would be able to 401 request S/MIME certificates using the protocol specified in this 402 document and such entity couldn't be distinguished from the 403 legitimate email account owner (unless some external sources of 404 information are consulted); 406 2. for email addresses with legitimate shared access/control by 407 multiple users, any such user would be able to request S/MIME 408 certificates using the protocol specified in this document and 409 such requests can't be attributed to a specific user without 410 consulting external systems (such as IMAP/SMTP access logs); 412 3. the protocol specified in this document is not suitable for use 413 with email addresses associated with mailing lists [RFC5321]. 414 While it is not always possible to guarantee that a particular 415 S/MIME certificate request is not from a mailing list address, 416 prohibition on inclusion of List-* header fields helps 417 Certificate Issuers to handle most common cases. 419 An email system in its turn depends on DNS. A third party that can 420 manipulate DNS MX records for a domain might be able to redirect 421 email and can get (at least temporary) read and reply access to it. 422 Similar considerations apply to DKIM TXT records in DNS. Use of 423 DNSSEC by email system administrators is recommended to avoid making 424 it easy to spoof DNS records affecting email system. However use of 425 DNSSEC is not ubiquitous at the time of publishing of this document, 426 so it is not required here. Also, many existing systems that rely on 427 verification of ownership of an email address, for example 2 factor 428 authentication systems used by banks or traditional certificate 429 issuance systems send email messages to email addresses, expecting 430 the owner to click on the link supplied in them (or to reply to a 431 message), without requiring use of DNSSEC. So the risk of not 432 requiring DNSSEC is presumed acceptable in this document. 434 Also see Security Considerations section of [RFC6376] for details on 435 how DKIM depends on the DNS and the respective vulnerabilities this 436 dependence has. 438 7. References 440 7.1. Normative References 442 [FIPS180-4] 443 National Institute of Standards and Technology, "Secure 444 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 445 . 448 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 449 Extensions (MIME) Part Two: Media Types", RFC 2046, 450 DOI 10.17487/RFC2046, November 1996, 451 . 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 459 Word Extensions: Character Sets, Languages, and 460 Continuations", RFC 2231, DOI 10.17487/RFC2231, November 461 1997, . 463 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 464 DOI 10.17487/RFC2818, May 2000, 465 . 467 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 468 Classes and Attribute Types Version 2.0", RFC 2985, 469 DOI 10.17487/RFC2985, November 2000, 470 . 472 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 473 Request Syntax Specification Version 1.7", RFC 2986, 474 DOI 10.17487/RFC2986, November 2000, 475 . 477 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 478 Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August 479 2004, . 481 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 482 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 483 . 485 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 486 DOI 10.17487/RFC5321, October 2008, 487 . 489 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 490 DOI 10.17487/RFC5322, October 2008, 491 . 493 [RFC5890] Klensin, J., "Internationalized Domain Names for 494 Applications (IDNA): Definitions and Document Framework", 495 RFC 5890, DOI 10.17487/RFC5890, August 2010, 496 . 498 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 499 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 500 RFC 6376, DOI 10.17487/RFC6376, September 2011, 501 . 503 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 504 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 505 . 507 [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized 508 Email Addresses in X.509 Certificates", RFC 8398, 509 DOI 10.17487/RFC8398, May 2018, 510 . 512 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 513 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 514 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 515 April 2019, . 517 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 518 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 519 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 520 April 2019, . 522 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 523 Kasten, "Automatic Certificate Management Environment 524 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 525 . 527 [RFC8616] Levine, J., "Email Authentication for Internationalized 528 Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, 529 . 531 7.2. Informative References 533 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 534 Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 535 2005, . 537 [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click 538 Functionality for List Email Headers", RFC 8058, 539 DOI 10.17487/RFC8058, January 2017, 540 . 542 Appendix A. Acknowledgements 544 Thank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben 545 Schwartz, Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, 546 Fraser Tweedale and Benjamin Kaduk for suggestions, comments, and 547 corrections on this document. 549 Author's Address 551 Alexey Melnikov 552 Isode Ltd 553 14 Castle Mews 554 Hampton, Middlesex TW12 2NP 555 UK 557 EMail: alexey.melnikov@isode.com