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

[Benjamin Kaduk <[e-mail]>]

Hi Rene,

Section 16.11 discusses what the IANA Designated Experts should do upon
receipt of a registration request, which is a distinct step from what
someone making a registration request of IANA should do.

I further note that the final bullet of the section says that "Algorithms
that do not meet the security requirements of the community and the
messages structures should not be registered"; it seems natural to me that
a Designated Expert would choose to consult the COSE WG email list in order
to get feedback from the community.

-Ben

On Mon, Feb 15, 2021 at 02:13:15PM -0500, Rene Struik wrote:
> Hi John:
> 
> I would be eager to have an answer to the question I posed earlier:
> 
>     /I could not find the procedure you seemingly had in mind below in
>     RFC 8152 (a search in RFC 8152 on the term "email" also did not
>     yield this info). Isn't this all described in Section 16.11 [1]? If
>     you could point me to what I am apparently missing, please let me know!/
> 
> 
> Since you seem to know much more about IETF processes than I do, any 
> timely help much appreciated! {I am sure it would also help others more 
> verses into technical matters than procedural questions.}
> 
> Best regards, Rene
> 
> On 2021-02-14 4:56 p.m., Rene Struik wrote:
> > Hi John:
> >
> > To my knowledge, I followed the steps described in Section 16.11 [1] 
> > (Expert Review Instructions), already in April 2019 (almost 2 years ago):
> >
> >     16.11. Expert Review Instructions
> >     All of the IANA registries established in this document are
> >     defined as expert review. This section gives some general
> >     guidelines forwhat the experts should be looking for, but they are
> >     being designated as experts for a reason, so they should be given
> >     substantial latitude.
> >
> >     Expert reviewers should take into consideration the following points:
> >
> >     [snip (enumeration of four aspects to consider)]
> >
> > I could not find the procedure you seemingly had in mind below in RFC 
> > 8152 (a search in RFC 8152 on the term "email" also did not yield this 
> > info). Isn't this all described in Section 16.11 [1]? If you could 
> > point me to what I am apparently missing, please let me know!
> >
> > In all fairness, I think you would have to agree that I did reach out 
> > to the relevant actors at the time, in good conscience, in a timely 
> > manner (in contrast to the language you used in your forelast email).
> >
> > Best regards, Rene
> >
> > Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11
> >
> > On 2021-02-14 4:08 p.m., John Mattsson wrote:
> >>
> >> Hi Rene,
> >>
> >> True, Jim used to be one the experts. My comment that you did not 
> >> talk to any of the experts is not true.
> >>
> >> The only IANA history I know of started on 6 Nov 2020 when Göran (one 
> >> of the experts) followed the procedure and sent a mail to the COSE 
> >> mailing list commenting and asking about the COSE registrations. I 
> >> and several other people in COSE WG seem to share Göran’s concerns. 
> >> You cannot expect COSE WG to read your draft before somebody send it 
> >> to the list. If I had written the draft I would personally had sent 
> >> in to COSE a long time ago. I wish someone would have helped you with 
> >> that.
> >>
> >> You need to ask Göran and the other two experts on the status but to 
> >> me it seems like the COSE WG is aligning on the technical aspects of 
> >> the IANA registrations:
> >>
> >> https://mailarchive.ietf.org/arch/browse/cose/?gbt=1&index=IEx4C67-IGkQ9BpI8DUFxhElcwA
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> *From: *Rene Struik <[e-mail]>
> >> *Date: *Sunday, 14 February 2021 at 20:11
> >> *To: *John Mattsson <[e-mail]>, Göran Selander 
> >> <goran.selander=[e-mail]>, "[e-mail]" 
> >> <[e-mail]>, "[e-mail]" <[e-mail]>
> >> *Subject: *(small timeline correction) Re: [COSE] 
> >> draft-ietf-lwig-curve-representations-13
> >>
> >> Correction: LWIG WGLC was in August 2019 and not August 2020, as I 
> >> mistakenly put in my previous note (i.e., already 18 1/2 months or 
> >> more than 1 1/2 years ago).
> >>
> >> See 
> >> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/ 
> >> <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/>
> >>
> >> On 2021-02-14 2:04 p.m., Rene Struik wrote:
> >>
> >>     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/
> >>     <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/>
> >>
> >>     - WGLC LWIG group: August 6, 2019;
> >>
> >>     - 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 <[e-mail]>
> >>         <mailto:[e-mail]>
> >>         *Date: *Wednesday, 13 January 2021 at 15:26
> >>         *To: *John Mattsson <[e-mail]>
> >>         <mailto:[e-mail]>, Göran Selander
> >>         <goran.selander=[e-mail]>
> >>         <mailto:goran.selander=[e-mail]>,
> >>         "[e-mail]" <mailto:[e-mail]> <[e-mail]>
> >>         <mailto:[e-mail]>, "[e-mail]"
> >>         <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
> >>         *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 <[e-mail]>
> >>                 <mailto:[e-mail]> on behalf of Rene
> >>                 Struik <[e-mail]>
> >>                 <mailto:[e-mail]>
> >>                 *Date: *Friday, 6 November 2020 at 20:37
> >>                 *To: *Göran Selander
> >>                 <goran.selander=[e-mail]>
> >>                 <mailto:goran.selander=[e-mail]>,
> >>                 "[e-mail]" <mailto:[e-mail]>
> >>                 <[e-mail]> <mailto:[e-mail]>,
> >>                 "[e-mail]" <mailto:[e-mail]>
> >>                 <[e-mail]> <mailto:[e-mail]>
> >>                 *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
> >>
> >>                     [e-mail]  <mailto:[e-mail]>
> >>
> >>                     https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
> >>
> >>                 -- 
> >>
> >>                 email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
> >>
> >>                 cell: [phone] | US: [phone]
> >>
> >>                 -->
> >>
> >>             -- 
> >>
> >>             email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
> >>
> >>             cell: [phone] | US: [phone]
> >>
> >>         -- 
> >>
> >>         email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
> >>
> >>         cell: [phone] | US: [phone]
> >>
> >>     -- 
> >>
> >>     email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
> >>
> >>     cell: [phone] | US: [phone]
> >>
> >> -- 
> >> email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
> >> cell: [phone] | US: [phone]
> >
> >
> > -- 
> > email:[e-mail]  | Skype: rstruik
> > cell: [phone] | US: [phone]
> 
> 
> -- 
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
> 

> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose