Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13

Rene Struik <rstruik.ext@gmail.com> Sun, 14 February 2021 19:04 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54B53A113E; Sun, 14 Feb 2021 11:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vjbM-g2xpXe; Sun, 14 Feb 2021 11:04:43 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929153A113F; Sun, 14 Feb 2021 11:04:43 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id d3so3480522qtr.10; Sun, 14 Feb 2021 11:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=/m0Y2SdwPqla7d0SvAcSGMu6HVvZRYFTOrRdBiQsA2o=; b=TDLznM5Oa4XGdh5iNXJPImM/1H0PzOF7r14yHsQnVPCGeR67vrYBw+m5uvqv78lgC9 3mo9H7ygMKOtkeHCV1H9Ec7Kd196bOZ9awC0j4xkaMj6Z0OrWpE4haqGZitJTOC1vely jD0ZCfZY+fH9jmzehR1/9sQ/4HbQLwFJlfRjalAnX2wHZ8OqDK2rMA0pTWxhdqWKS+i5 BiFoGK3j8HXqifmCxDDFDvfgA4bZJYm10ekASy+Z9g0Zhi0RrqA5vjAy9QiOu3BfPLKQ Pi/kbBsisPkpweJ3Mn06DaI2lrKesSo6a5g3xvcSvYJlJpf5kXHw657373N5gSdJAiiy LRUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/m0Y2SdwPqla7d0SvAcSGMu6HVvZRYFTOrRdBiQsA2o=; b=pdvxF1erXPrp9RL9AzUFjg+CubdrOXP0+Xph24APQedUtcnzcm/6pIwJ1U6uvVv/fu ygPuJhJ1JJw5Dxpq6vHbwGMznc4wt7+IC609JI+zzgRjjVgYGH/VnZU1HfxBPZ6jHzB8 9D96IqwXSb1gewo8DbxAUQCe0qVW3VJEwPgn9IpBOxe3OyxnPuraI5ncRUoRygcJdEQ1 CfyKOkZDNBvBptqh+hcwY3wmm9nvHD2UYC0rtYR+oP2AbPsl5buNIJij+x1jvTn87YlN CUcH30TnlNAAo4Ohhs2mh49/IdlG3DYEp6Kta+hoYy8DoNXwwhUL+2+KJ06PAy4xQIg/ TD4w==
X-Gm-Message-State: AOAM533hOWs02wv8Y82Dn2AtFhMhhaHaAyEd1eWUVq2k2dfb/qUxDge3 oLMxb+NHApWRmWApy3jZf+Au5HMjiWw=
X-Google-Smtp-Source: ABdhPJzP2zVBU0H9WXJwHr/ONox0gN+SwOnDsL20k5v1soSNTfsL2rzKBlkIlf0LJ1dsI9aBdJIGwA==
X-Received: by 2002:aed:2644:: with SMTP id z62mr5925276qtc.72.1613329482169; Sun, 14 Feb 2021 11:04:42 -0800 (PST)
Received: from ?IPv6:2607:fea8:8a0:1397:8508:138:2a28:f134? ([2607:fea8:8a0:1397:8508:138:2a28:f134]) by smtp.gmail.com with ESMTPSA id o46sm9797754qtb.76.2021.02.14.11.04.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 11:04:41 -0800 (PST)
To: John Mattsson <john.mattsson@ericsson.com>, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>, "lwip@ietf.org" <lwip@ietf.org>, "cose@ietf.org" <cose@ietf.org>
References: <HE1PR0702MB36745AEC1C6E929CA4D9A1C7F4ED0@HE1PR0702MB3674.eurprd07.prod.outlook.com> <be8f9113-a74a-7358-383c-927e7fab0f13@gmail.com> <3DEA816D-EBFE-4914-B327-5EA11ECABF45@ericsson.com> <15a95ece-d580-1a28-24f0-0ecb71631c70@gmail.com> <f1f45799-8469-842a-c1d3-81c5362a68f1@gmail.com> <479BBEDE-79B8-43F7-BC3F-6525FE23AAD1@ericsson.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <1d30ed02-429b-284b-3a19-d12be1cb3370@gmail.com>
Date: Sun, 14 Feb 2021 14:04:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <479BBEDE-79B8-43F7-BC3F-6525FE23AAD1@ericsson.com>
Content-Type: multipart/alternative; boundary="------------B25E27AFFFCB6636423F71F1"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/YneMSksc57ercNRoopdSGx2X0MI>
Subject: Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Feb 2021 19:04:47 -0000

Hi John:

I did have a brief look at my past correspondence on iana-cose code 
points, where I discussed this with Jim Schaad (designated iana cose 
expert over the relevant time period):
- email correspondences {March 27, 2019; April 12, 2019; April 15, 2019};
- f/u. discussions w/ Jim Schaad (triggered by trying to help out Pascal 
Thubert on his ap-nd Editor queue draft): phone call {Thu March 16, 
2020}; email correspondence {April 6/7/22/25, 2020}

History of iana sections in curve-draft document:
- iana/cose section has been in there since April 14, 2019 (v04 of the 
draft). See 
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/
- WGLC LWIG group: August 4, 2020;
- IETF Last-Call: August 24, 2020 (two-week);
- your comment: Nov 9, 2020
- your (nontechnical) email below: today, Feb 14, 2021 (32 days after my 
last email to the list).

Contrary to what you seem to suggest below, my records above indicate I 
have reached out to the relevant people already almost two (!) years 
ago, in good conscience (where email and phone conversations with Jim 
Schaad were productive, with 1-2 days feedback loop). I have trouble 
understanding why during all this time the technical points you seem to 
take issue with have not been narrowed down (as I repeatedly suggested 
offline and which is good engineering practice). Please note that even 
something as simple an uncontroversial as registering Wei25519 and 
Wei448 has not been stricken off the list since the November 2020 note. 
I think one should reflect why this (in an Internet *Engineering* Task 
Force).

Best regards, Rene

On 2021-02-14 3:13 a.m., John Mattsson wrote:
>
> Hi Rene,
>
> >I value your feedback, even though you brought up your points more 
> than two months after the
>
> >IETF Last-Call.
>
> All the comments has been purely regarding the IANA registrations for 
> COSE. To my understanding you did not discuss these registrations with 
> the dedicated IANA experts or the COSE WG beforehand. The suggested 
> COSE registration are quite strange. Any delay is purely due to you 
> not discussing and anchoring these registrations. I have suggested 
> that that this issue is discussed at the interim on Tuesday, but it is 
> not my job to drive your registrations. I am just commenting on the 
> questions from the dedicated IANA experts.
>
> You can always remove the COSE registrations, but I think that would 
> be sad. I agree with you that a registration for Wei25519 is good to 
> have. Another alternative is to move the registration to a separate draft.
>
> >I uploaded a new version of the lwig curve draft [1], changing the 
> intended status to "standards track". I hope
>
> >this helps.
>
> You cannot just change the status from “informational” to “standards 
> track”. They are very different things. Informational is just general 
> information, while standards track means IETF consensus and 
> recommendation. Changing the status would (I assume) require wg 
> consensus and then redoing the last calls.
>
> /John
>
> *From: *Rene Struik <rstruik.ext@gmail.com>
> *Date: *Wednesday, 13 January 2021 at 15:26
> *To: *John Mattsson <john.mattsson@ericsson.com>, Göran Selander 
> <goran.selander=40ericsson.com@dmarc.ietf.org>, "lwip@ietf.org" 
> <lwip@ietf.org>, "cose@ietf.org" <cose@ietf.org>
> *Subject: *Re: [COSE] draft-ietf-lwig-curve-representations-13
>
> Hi Goran, John:
>
> Please let me know if my response to the COSE mailing list (Dec 19th) 
> works for you. If you have comments, please suggest constructive 
> improvements.
>
> I really would like to get closure on this.
>
> I value your feedback, even though you brought up your points more 
> than two months after the IETF Last-Call. I hope we can move forward 
> without undue delays.
>
> Thanks for your help, Rene
>
> On 2020-12-19 11:01 a.m., Rene Struik wrote:
>
>     Dear John:
>
>     Based on your review and other feedback received, I slightly
>     updated the draft and posted the latest revision as [1].
>
>     Your review below (of Nov 6, 2020) seems to bring up three topics,
>     viz.: (1) definition of Wei25519 and Wei448 vs. verbiage in NIST
>     docs; (2) need for iana registrations for ECDSA25519 and ECDSA448;
>     (3) need for iana registrations ECDH25519 and ECDH448.
>
>     Please find below some feedback.
>
>     General feedback:
>
>     Please bear in mind that the specifications of ECDSA25519 and
>     ECDH25519 in the lwig curve document aim to yield schemes that are
>     strictly NIST-compliant (i.e., these would allow FIPS 140-2
>     accreditation if the curves would be in the "NIST recommended"
>     set). See also Note 2 of Section 4.1 of [1]. A similar remark
>     applies to ECDSA448 and ECDH448.
>
>     Detailed feedback:
>
>     (1) Definition of Wei25519 and Wei448 vs. verbiage in NIST docs.
>
>     Draft NIST SP 800-186 indeed defines a short-Weierstrass version
>     of Curve25519 [dubbed W-25519] and FIPS 186-5 allows its use;
>     similar for Curve448 [dubbed W-448 there]). I have now added
>     references to these draft specifications in the lwig-curve draft.
>     I have double-checked all domain parameters, mappings between
>     curve models, tables of isogeny details in the lwig draft and
>     provided Sage scripts for the CFRG crypto panel review at the
>     time. I do anticipate that NIST will arrive at the same values in
>     their final publication when they decide to publish this. (I am
>     happy to share Sage scripts for this purpose.)
>
>     (2) Need for iana registrations for ECDSA25519 and ECDSA448.
>
>     ECDSA is determined by an instantiation of hash function, curves,
>     and representation conventions for inputs and outputs (i.e.,
>     message representation, curve point representation, and signature
>     representation).
>     a) ECDSA448 uses SHAKE256 under the hood, which is currently not
>     defined with COSE. Hence, my request to register ECDSA w/ SHAKE256
>     and Wei448 as "ECDSA448".
>     b) ECSA25519 uses SHA256 and Wei25519 under the hood. I thought to
>     request to register "ECDSA25519" since this would allow
>     referencing the quite careful write-up (Section 4.3), including
>     bit/byte ordering, checks, and nondeterministic behavior (and,
>     thereby, keeping this concise). Please note that this is very
>     similar to the COSE IANA registry for "ES256k1" (ECDSA w/ SHA256
>     and Bitcoin curve secp256k1).
>
>     (3) Need for iana registrations ECDH25519 and ECDH448.
>
>     ECDH25519 and ECDH448 are co-factor Diffie-Hellman key
>     establishment schemes and can, therefore, not be based on
>     (cofactorless) Diffie-Hellman, as defined in RFC 8152. (Please
>     note that there is no difference for the NIST curves, which all of
>     co-factor h=1, but in our case one has h=8 and h=4, respectively).
>     Here, one should note that the ECDH25519 and ECDH448 write-ups
>     (Section 4.1 and 4.3) quite carefully cross-reference co-factor
>     ECDH in a NIST-compliant way. Apart from the co-factor ECDH vs.
>     ECDH issue and objective to comply with all strict NIST validation
>     checks, the objective was also to make sure that ECDH25519 and
>     ECDH448 can be used in settings where either or both parties uses
>     ephemeral keys (which is more flexible than what RFC 8152
>     allows).  Hence, the request to register "ECDH25519" and
>     "ECDH448", to make sure this covers the intent of these schemes
>     accurately and with precise description.
>
>     It is possible that I overlooked something in this assessment. If
>     so, any constructive suggestions are welcome.
>
>     Ref: [1]
>     https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19
>     <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19>
>
>     Best regards, Rene
>
>     On 2020-11-06 5:04 p.m., John Mattsson wrote:
>
>         Hi,
>
>         I looked through this draft again. I think it is a very good
>         draft and I think it will be a solution to some of the
>         problems IoT devices have with Ed25519. I will bring up this
>         draft for discussion in the LAKE WG at IETF 109.
>
>         I find it strange that the IANA registration has not been
>         coordinated with COSE WG at all. I am a bit surprised to see
>         IANA registrations for COSE/JOSE/PKIX/CMS at all in a LWIG
>         draft (is that in charter?). If LWIG wants to register new
>         algorithms, I think LWIG at a minimum should coordinate with
>         COSE WG and other groups. I think this draft should be
>         presented at the next COSE WG meeting.
>
>         I support registration of W-25519 and W-448 curves as long
>         they agree with NIST. I would like answers to the questions
>         why ECDSA25519 and ECDH25519 are needed at all. There is no
>         ECDSAP256 and no ECDHP256, so why are specific algorithm
>         registration needed for W-25519?  It makes no sense to me that
>         a special signature registration is needed for COSE but not
>         for PKIX? If PKIX can use ecdsa-with-SHA256 why cannot COSE
>         use ES256?
>
>         I don't think ANSI X9.62 is an acceptable normative reference.
>         NIST just removed the normative reference to ANSI X9.62 in SP
>         186-5.
>
>         Cheers,
>
>         John
>
>         *From: *COSE <cose-bounces@ietf.org>
>         <mailto:cose-bounces@ietf.org> on behalf of Rene Struik
>         <rstruik.ext@gmail.com> <mailto:rstruik.ext@gmail.com>
>         *Date: *Friday, 6 November 2020 at 20:37
>         *To: *Göran Selander
>         <goran.selander=40ericsson.com@dmarc.ietf.org>
>         <mailto:goran.selander=40ericsson.com@dmarc.ietf.org>,
>         "lwip@ietf.org" <mailto:lwip@ietf.org> <lwip@ietf.org>
>         <mailto:lwip@ietf.org>, "cose@ietf.org" <mailto:cose@ietf.org>
>         <cose@ietf.org> <mailto:cose@ietf.org>
>         *Subject: *Re: [COSE] draft-ietf-lwig-curve-representations-13
>
>         Hi Goran:
>
>         Please find below some brief feedback on your note:
>
>         - the naming wei25519 has been around since the first draft
>         (Nov 13, 2017, i.e., 3 years minus 1 week ago), see [1]. NIST
>         indeed produced two draft documents, viz. Draft NIST SP
>         800-186 and Draft FIPS Pub 186-5 (on October 31, 2019), which
>         generated lots of (to my knowledge still unresolved) comments
>         during public review. It is hard to refer to that document,
>         since it is only a draft and unfortunately has quite a few errors.
>
>         - earlier versions of the lwig draft have received reviews by
>         the crypto review panel (Stanislavslav Smyshlyaev), iotdir
>         early-review (Daniel Migault); the sections on COSE/JOSE code
>         point assignments resulted from a phone call and various email
>         exchanges with Jim Schaad; the section on PKIX/CMS was
>         suggested during IETF Last-Call secdir-review (Russ Housley)
>         and reviewed by him. The document had IETF Last-Call Aug 24,
>         2020. See, e.g., the status pages [1].
>
>         - ECDSA has been around since 1999, has been widely
>         standardized, and has seen lots of analysis, where ECDSA25519
>         is simply yet another instantiation. Signature generation and
>         verification times for ECDSA25519 should be similar to those
>         of Ed25519 (since timing is dominated by scalar
>         multiplication, where one could simply use Montgomery
>         arithmetic [3]). In my personal view, ECDSA25519 may be more
>         secure than Ed25519 (if only because it is non-deterministic,
>         see Security section [6]); similar side-channel care has to be
>         taken in either case.
>
>          - As mentioned in the draft, one can easily switch between
>         Wei25519 and Curve25519 (which requires a single field
>         addition or subtraction only, i.e., <.01%, see Appendix E.2
>         [7]). As mentioned in the draft, one could use Wei25519.-3
>         with an existing generic implementation that hardcodes the
>         domain parameter a=-3, but needs to compute an isogeny and
>         dual isogeny for this (adding 5-10% cost, see Appendix G.2
>         [8]]) and a ~9.5kB table (see Section 5.3 [4]). However, if
>         one already has generic hardware support, one may still have a
>         significant win (see Section 6 [5]).
>
>         - The isogeny for Wei25519.-3 has odd degree l=47, which is
>         co-prime with the order of the curve, so is in fact
>         invertible. With Wei448.-3, the isogeny has degree l=2, so is
>         not invertible; however, this does not really matter, since it
>         is invertible with correctly generated public-private key
>         pairs (which have prime/odd order) and the factor two is
>         absorbed with co-factor ECDH, where h=4 then.
>
>         I hope this helps.
>
>         (*) For ease of tracking, it would help if iana related
>         comments are flagged in the subject line (e.g., include (iana)
>         in the beginning hereof).
>
>         Best regards, Rene
>
>         Ref with hyperlinks:
>
>         [1]
>         https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00
>         <https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00>
>
>         [2]
>         https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
>         <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/>
>
>         [3]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3>
>
>         [4]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3>
>
>         [5]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6>
>
>         [6]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8>
>
>         [7]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2>
>
>         [8]
>         https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2
>         <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2>
>
>         On 2020-11-06 11:19 a.m., Göran Selander wrote:
>
>             Hi,
>
>             Apologies for cross-posting LWIG and COSE. I had a brief
>             look at draft-ietf-lwig-curve-representations-13 and
>             noticed it registers a lot of new COSE(andJOSE, PKIX, and
>             CMS) algorithms. Has this draft been discussed in
>             COSE(JOSE/CURDLE)? If not, perhaps it should be before
>             being progressed?
>
>             1.The draft needs to manage the overlap with NIST SP
>             800-186, which should be referenced and mappings, name of
>             curves, etc. aligned. The draft defines Wei25519 and
>             Wei448. It is unclear if these are identical to W-25519,
>             W-448 as defined in NIST SP 800-186. We probably would not
>             want two slightly different definitions and/or names,
>             multiple COSE code points, etc.
>
>             1.The draft registers the COSE algorithm "ECDSA25519" as
>             "ECDSA with SHA-256 and curve Wei25519". That is not how
>             the other COSE signature algorithms work. They work like
>             PKIX where the curve is given by the public key. Also, why
>             cannot W-25519 be used with the existing ES256 signature
>             algorithm?
>
>             2.The draft registers the COSE algorithm "ECDH25519".
>             There are no COSE ECDH algorithms for P-256, why is anECDH
>             algorithm for W-25519 be needed?
>
>             Other questions. I may have missed it, but
>
>             2.is it described what are the expected security
>             properties of ECDSA25519(including mapping) compared to
>             Ed25519? For example w.r.t. side channel attacks?
>
>             3.has any performance measurements been made comparing
>             ECDSA25519 (including mapping) and Ed25519?
>
>             4.similar questions on security and performance with
>             Wei25519.-3 instead of Wei25519. If I understand right,
>             the former mapping is not reversible, but could benefit
>             from optimized code with hardcoded domain parameters.
>
>             5.ANSI X9.62-2005 was withdrawn in 2015 and is behind a
>             paywall, is this reference necessary?
>
>             Göran
>
>
>
>
>             _______________________________________________
>
>             COSE mailing list
>
>             COSE@ietf.org  <mailto:COSE@ietf.org>
>
>             https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
>
>         -- 
>
>         email:rstruik.ext@gmail.com  <mailto:rstruik.ext@gmail.com>  | Skype: rstruik
>
>         cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
>         -->
>
>     -- 
>
>     email:rstruik.ext@gmail.com  <mailto:rstruik.ext@gmail.com>  | Skype: rstruik
>
>     cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> -- 
> email:rstruik.ext@gmail.com  <mailto:rstruik.ext@gmail.com>  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867