Subject: [Cacao] Initial Problem Set

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 09:49:02 -0600

All,

I wanted to start some discussion on some of the initial problems (not all) that we have already identified that need to be solved with this type of solution. Some of the solutions to these will have elements we can borrow from other work. Also, keep in mind all of this needs to work in native JSON.

Need the ability to document a single command
Human executed commands
Native Machine commands (Cisco IOS, Juniper, SEP, OpenC2, SNMP, NETCONF, YANG, etc)
What device or system does the command target (DesktopOS 10 at IP address 10.0.0.2, Firewall BAR at 192.168.0.2)
What class of devices or systems does the command target (DesktopOS 10 at patch level 4, Firewall FOO ver 10)
Need the ability to document a chain of commands
Need to know if there is temporal logic or conditional logic associated between commands
Need to know if commands are sequenced or if they can be run in parallel
Need to know if there are fall through or fail-to-next commands
Need tracking to know how to back out commands that fail and how far up the tree you need to back out on failure 
Need ability to provide Digital signatures at the command, the command chain (tree), and COA Project levels
These digital signatures need to be included in the payload themselves
Need to be able to sign a section or part of the JSON text data
They need to be in parallel and in series. Meaning, a command may individually be signed by more than one people.  The command and a signature may also be signed multiple times in series.
Example: Company X that makes DesktopOS 10 signs a command that says it will resolve malware Z on DesktopOS 10 patch version 4. Big Bank Foo may then sign that (command + Company sig) and say they have verified it and it works. Some ISAC may then sign that (command + Company sig + Big Bank Foo sig) and then send it out to their eco-system
Signatures need ability to identify what assertions someone is making.  
We need to know what the types of assertions should be (it works, it has been verified, it has been reviewed, it may work, it seems to work, etc)
Need ability to get responses at the individual command level, the chain of commands level, and the COA Project level. 
Need to identify the types of responses that can be returned and what are the types of command codes / response codes that should be returned
Need to identify and have negotiation between systems if the responses should be pushed or pulled.
Need to know how the individual response can impact the next steps in the chain.

Things we already know how to do.. We know how to make this work in a graph, we know how to make this work with versioning, we know how to tie these to existing Cyber Threat Intelligence.  

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

---

From: Barry Greene <[email-masked]>
Date: Wed, 19 Sep 2018 06:34:58 +0800

Hi Bret,

What you have below was done in Cisco’s TIDP/TMS architecture. 

Barry

> On Sep 18, 2018, at 23:49, Bret Jordan <[email-masked]> wrote:
> 
> All,
> 
> -- 
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 18 Sep 2018 22:06:20 -0400

Hi Bret,

On Tue, Sep 18, 2018 at 6:35 PM Barry Greene <[email-masked]> wrote:

> Hi Bret,
>
> What you have below was done in Cisco’s TIDP/TMS architecture..
>
> Barry
>
> I wanted to start some discussion on some of the initial problems (not
> all) that we have already identified that need to be solved with this type
> of solution. Some of the solutions to these will have elements we can
> borrow from other work. Also, keep in mind all of this needs to work in
> native JSON.
>
>
>    1. Need the ability to document a single command
>       1. Human executed commands
>       2. Native Machine commands (Cisco IOS, Juniper, SEP, OpenC2, SNMP,
>       NETCONF, YANG, etc)
>       3. What device or system does the command target (DesktopOS 10 at
>       IP address 10.0.0.2, Firewall BAR at 192.168.0.2)
>       4. What class of devices or systems does the command target
>       (DesktopOS 10 at patch level 4, Firewall FOO ver 10)
>
> Additional data classes of IODEF, also the SCI extension.
https://tools.ietf.org/html/rfc7970

>
>    1. Need the ability to document a chain of commands
>       1. Need to know if there is temporal logic or conditional logic
>       associated between commands
>       2. Need to know if commands are sequenced or if they can be run in
>       parallel
>       3. Need to know if there are fall through or fail-to-next commands
>       4. Need tracking to know how to back out commands that fail and how
>       far up the tree you need to back out on failure
>
>
Take a look at the MILE work more closely, there are lessons learned as
much of this has been done.  Even if you don't want to use the work, there
's no reason to have us all debate the same things again rather than build
from experience.
IODEF predicate logic:  It's simple and more compact.
https://tools.ietf.org/html/rfc8274#page-7

>    1. Need ability to provide Digital signatures at the command, the
>    command chain (tree), and COA Project levels
>       1. These digital signatures need to be included in the payload
>       themselves
>       2. Need to be able to sign a section or part of the JSON text data
>       3. They need to be in parallel and in series. Meaning, a command
>       may individually be signed by more than one people.  The command and a
>       signature may also be signed multiple times in series.
>          1. Example: Company X that makes DesktopOS 10 signs a command
>          that says it will resolve malware Z on DesktopOS 10 patch version 4. Big
>          Bank Foo may then sign that (command + Company sig) and say they have
>          verified it and it works. Some ISAC may then sign that (command + Company
>          sig + Big Bank Foo sig) and then send it out to their eco-system
>       4. Signatures need ability to identify what assertions someone is
>       making.
>          1. We need to know what the types of assertions should be (it
>          works, it has been verified, it has been reviewed, it may work, it seems to
>          work, etc)
>
> You also need to consider origin authentication and multi-hop
authentication.  There was a lot of work that went into the requirements
analysis across areas of the IETF as not to make RID and other MILE
protocols specific to incidents or even XML.
https://tools.ietf.org/html/rfc6545

Yes, this is XML and you want JSON, using JOSE, I presume.  Still, the gap
analysis I think will be quite useful as I think you are missing
requirements we already came up against.  It will speed your work up to
leverage existing work.

>
>    1. Need ability to get responses at the individual command level, the
>    chain of commands level, and the COA Project level.
>       1. Need to identify the types of responses that can be returned and
>       what are the types of command codes / response codes that should be returned
>       2. Need to identify and have negotiation between systems if the
>       responses should be pushed or pulled.
>       3. Need to know how the individual response can impact the next
>       steps in the chain.
>
>
> You also need to consider internationalization, which has already been
done in the MILE work.  This level of detail helps a lot for
interoperability. There were 3 interoperable implementations of RID, so
testing was done, lessons can be learned.  I'm not sure how may IODEF
implementations there were/are, but many more than that.

Once again, please do the gap analysis to save us all time.  There are
other MILE documents that may be useful, they can be found off the
documents link of the charter page.  ROLIE and XMPP Grid were also designed
to work with any format and I believe are more flexible than RID, so there
is much that can be gleaned from these efforts as well as the DOTS work.

Best regards,
Kathleen

>
> Things we already know how to do.. We know how to make this work in a
> graph, we know how to make this work with versioning, we know how to tie
> these to existing Cyber Threat Intelligence.
>
>
> Thanks,
> Bret

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Wed, 19 Sep 2018 08:30:58 +0000

Hi Bret, Kathleen

would that be something that could work as some kind of gap analysis? https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md . It is no real gap analysis, this FAQ would rather highlight the differences. I just took two samples to show how that could look like and if that is what could be helpful. We could also include comments here like… "CACAO makes use of XY to achieve its goal".

best regards
Carolin

From: Cacao [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, September 19, 2018 4:06 AM
To: Barry Greene <[email-masked]>
Cc: [email-masked]; Bret Jordan <[email-masked]>
Subject: Re: [Cacao] Initial Problem Set

Hi Bret,

On Tue, Sep 18, 2018 at 6:35 PM Barry Greene <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bret,

Barry

On Sep 18, 2018, at 23:49, Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
All,

I wanted to start some discussion on some of the initial problems (not all) that we have already identified that need to be solved with this type of solution. Some of the solutions to these will have elements we can borrow from other work. Also, keep in mind all of this needs to work in native JSON..

     *   Human executed commands
     *   Native Machine commands (Cisco IOS, Juniper, SEP, OpenC2, SNMP, NETCONF, YANG, etc)
     *   What device or system does the command target (DesktopOS 10 at IP address 10.0.0.2, Firewall BAR at 192.168.0..2)
     *   What class of devices or systems does the command target (DesktopOS 10 at patch level 4, Firewall FOO ver 10)
Additional data classes of IODEF, also the SCI extension.
https://tools.ietf.org/html/rfc7970

     *   Need to know if there is temporal logic or conditional logic associated between commands
     *   Need to know if commands are sequenced or if they can be run in parallel
     *   Need to know if there are fall through or fail-to-next commands
     *   Need tracking to know how to back out commands that fail and how far up the tree you need to back out on failure

Take a look at the MILE work more closely, there are lessons learned as much of this has been done.  Even if you don't want to use the work, there 's no reason to have us all debate the same things again rather than build from experience.
IODEF predicate logic:  It's simple and more compact.
https://tools.ietf.org/html/rfc8274#page-7

  1.  Need ability to provide Digital signatures at the command, the command chain (tree), and COA Project levels

     *   These digital signatures need to be included in the payload themselves
     *   Need to be able to sign a section or part of the JSON text data
     *   They need to be in parallel and in series. Meaning, a command may individually be signed by more than one people.  The command and a signature may also be signed multiple times in series.

        *   Example: Company X that makes DesktopOS 10 signs a command that says it will resolve malware Z on DesktopOS 10 patch version 4. Big Bank Foo may then sign that (command + Company sig) and say they have verified it and it works. Some ISAC may then sign that (command + Company sig + Big Bank Foo sig) and then send it out to their eco-system

     *   Signatures need ability to identify what assertions someone is making.

        *   We need to know what the types of assertions should be (it works, it has been verified, it has been reviewed, it may work, it seems to work, etc)
You also need to consider origin authentication and multi-hop authentication.  There was a lot of work that went into the requirements analysis across areas of the IETF as not to make RID and other MILE protocols specific to incidents or even XML.
https://tools.ietf.org/html/rfc6545

Yes, this is XML and you want JSON, using JOSE, I presume.  Still, the gap analysis I think will be quite useful as I think you are missing requirements we already came up against.  It will speed your work up to leverage existing work.

  1.  Need ability to get responses at the individual command level, the chain of commands level, and the COA Project level.

     *   Need to identify the types of responses that can be returned and what are the types of command codes / response codes that should be returned
     *   Need to identify and have negotiation between systems if the responses should be pushed or pulled.
     *   Need to know how the individual response can impact the next steps in the chain.

You also need to consider internationalization, which has already been done in the MILE work.  This level of detail helps a lot for interoperability. There were 3 interoperable implementations of RID, so testing was done, lessons can be learned.  I'm not sure how may IODEF implementations there were/are, but many more than that.

Once again, please do the gap analysis to save us all time.  There are other MILE documents that may be useful, they can be found off the documents link of the charter page.  ROLIE and XMPP Grid were also designed to work with any format and I believe are more flexible than RID, so there is much that can be gleaned from these efforts as well as the DOTS work.

Best regards,
Kathleen

Thanks,
Bret

--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao
--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Sep 2018 10:11:26 -0400

Hi Carolin,

Thanks for starting something to help!  I think that could be a good
starting point.  I'd be interested to see the requirements matched up
against what exists and what can be re-used or what can be a lesson learned
as well.  IODEF carries the CoAs that used to be in RID and IODEF has a
nesting capability as well as a way to lay our the format to allow for
predicate logic, so analysis on that would be interesting as well.  It can
be used for chains of connected events/incidents.  Understanding what
doesn't work for your new effort would help to understand why it's needed
and how it is better.

Then for RID, there is lots that is met in the requirement list that was
sent out and some requirements that I suggested (there are more) that were
learned from time and experience on essentially the same problem.

Barry - understanding more on your work and the Cisco products mentioned
would be helpful too.  If standards were used or not and what can be
integrated into this effort or what can be a lesson learned to improve for
this effort.

This will be very helpful for a BoF to be successful.  You'll get derailed
otherwise.

Thank you,
Kathleen

On Wed, Sep 19, 2018 at 4:31 AM <[email-masked]>
wrote:

> Hi Bret, Kathleen
>
>
>
> would that be something that could work as some kind of gap analysis?
> https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md . It is no
> real gap analysis, this FAQ would rather highlight the differences. I just
> took two samples to show how that could look like and if that is what could
> be helpful. We could also include comments here like… "CACAO makes use of
> XY to achieve its goal".
>
>
>
> best regards
> Carolin
>
>
>
> *From:* Cacao [mailto:[email-masked]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Wednesday, September 19, 2018 4:06 AM
> *To:* Barry Greene <[email-masked]>
> *Cc:* [email-masked]; Bret Jordan <[email-masked]>
> *Subject:* Re: [Cacao] Initial Problem Set
>
>
>
> Hi Bret,
>
>
>
>
>
>
>
> On Sep 18, 2018, at 23:49, Bret Jordan <[email-masked]
> <[email-masked]>> wrote:
>
> All,
>
>
>
> native JSON..
>       IP address 10.0.0.2, Firewall BAR at 192.168.0..2)
>    1. Example: Company X that makes DesktopOS 10 signs a command that
>          says it will resolve malware Z on DesktopOS 10 patch version 4. Big Bank
>          Foo may then sign that (command + Company sig) and say they have verified
>          it and it works. Some ISAC may then sign that (command + Company sig + Big
>          Bank Foo sig) and then send it out to their eco-system
>
>
>    1. Signatures need ability to identify what assertions someone is
>       making.
>
>
>    1. We need to know what the types of assertions should be (it works,
>          it has been verified, it has been reviewed, it may work, it seems to work,
>          etc)
>

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Wed, 19 Sep 2018 14:26:00 +0000

Hi Kathleen

ok thanks for the feedback. I have a question to understand this part better: " I'd be interested to see the requirements matched up against what exists and what can be re-used or what can be a lesson learned as well.  IODEF carries the CoAs that used to be in RID and IODEF has a nesting capability as well as a way to lay our the format to allow for predicate logic, so analysis on that would be interesting as well.  It can be used for chains of connected events/incidents.  Understanding what doesn't work for your new effort would help to understand why it's needed and how it is better."

Since the goals of both initiatives are different, I struggle a bit. Technically we should always discuss what concepts work for which use case. Like for instance do we need an authentication somewhere or not, and we don't re-invent the authentication. We check how it is usually done today. Is that what you are referring to when you mention the predicate logic etc? So, since MILE already worked on exchange formats for incidents even if their goal was different, we might have similar formatting requirements when we discuss the reactions to incidents? (just picking the formatting example here).

best regards
Carolin

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Wednesday, September 19, 2018 4:11 PM
To: Baumgartner Carolin <[email-masked]>
Cc: Barry Greene <[email-masked]>; [email-masked]; Bret Jordan <[email-masked]>
Subject: Re: [Cacao] Initial Problem Set

Hi Carolin,

Thanks for starting something to help!  I think that could be a good starting point.  I'd be interested to see the requirements matched up against what exists and what can be re-used or what can be a lesson learned as well.  IODEF carries the CoAs that used to be in RID and IODEF has a nesting capability as well as a way to lay our the format to allow for predicate logic, so analysis on that would be interesting as well.  It can be used for chains of connected events/incidents.  Understanding what doesn't work for your new effort would help to understand why it's needed and how it is better.

Then for RID, there is lots that is met in the requirement list that was sent out and some requirements that I suggested (there are more) that were learned from time and experience on essentially the same problem.

Barry - understanding more on your work and the Cisco products mentioned would be helpful too.  If standards were used or not and what can be integrated into this effort or what can be a lesson learned to improve for this effort.

This will be very helpful for a BoF to be successful.  You'll get derailed otherwise.

Thank you,
Kathleen

On Wed, Sep 19, 2018 at 4:31 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bret, Kathleen

best regards
Carolin

From: Cacao [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
Sent: Wednesday, September 19, 2018 4:06 AM
To: Barry Greene <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Bret Jordan <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cacao] Initial Problem Set

Hi Bret,

Barry

Best regards,
Kathleen

Thanks,
Bret

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Sep 2018 14:06:33 -0400

Hello Carolin,

Thanks for your efforts here.

On Wed, Sep 19, 2018 at 10:26 AM <[email-masked]>
wrote:

> Hi Kathleen
>
>
>
> ok thanks for the feedback. I have a question to understand this part
> better: " I'd be interested to see the requirements matched up against
> what exists and what can be re-used or what can be a lesson learned as
> well.  IODEF carries the CoAs that used to be in RID and IODEF has a
> and how it is better."
> Since the goals of both initiatives are different, I struggle a bit.
> Technically we should always discuss what concepts work for which use case.
> Like for instance do we need an authentication somewhere or not, and we
> don't re-invent the authentication. We check how it is usually done today.
> Is that what you are referring to when you mention the predicate logic etc?
> So, since MILE already worked on exchange formats for incidents even if
> their goal was different, we might have similar formatting requirements
> when we discuss the reactions to incidents? (just picking the formatting
> example here).
>

The gap analysis may wind up just showing the gap, but I am hoping that
there will be pieces of knowledge that can be gleaned from prior efforts.
 Your authentication example is good.  There may be a need for it and the
requirements may guide the selection of a solution that either works for
both or that the new work has requirements (or technology evolved) that
clearly show the need for something new.

MILE protocols all support sharing formatted data, XML, JSON, etc. and are
not restricted to IODEF.  There are 3 protocols to look at and I would hope
that some could be reused, or that similar patterns may be useful.

Does that help?

Thanks,
Kathleen

>
> best regards
>
> Carolin
>
>
>
> *From:* Kathleen Moriarty [mailto:[email-masked]]
> *Sent:* Wednesday, September 19, 2018 4:11 PM
> *To:* Baumgartner Carolin <[email-masked]>
> *Cc:* Barry Greene <[email-masked]>; [email-masked]; Bret Jordan <
> [email-masked]>

-- 

Best regards,
Kathleen

---

From: Bret Jordan <[email-masked]>
Date: Wed, 19 Sep 2018 12:52:09 -0600

I agree and hope we can borrow elements, concepts, ideas from other work, not just work here in the IETF.  The way I like to approach problems like this is to break them up in to phases. The first of which is the concept phase. Its purpose is to iterate out a list of requirements and problems we need to solve that are tightly scoped to the project at hand. 

To this end, I have I sent a very short list of initial problems to the list a few days ago and a draft last week. The draft contains a few high level requirements. These lists are not complete and not even the full list that we have worked through prior to uploading the draft. But it was meant as a starting point. My hope is that it would foster dialog and communication like “why is X a requirement, how do you plan on solving X, have you thought about problem Y, what about use-case W or requirement Z”. 

Once we have our concept phase done and fleshed out, I would like us to do a lit-review of prior work (even though most of us have already read all of these existing work products) to help us understand what has been done before and what can be reused. Some of us may just be able to point certain requirements at certain sections of existing work, which will be fantastic. 

Doing this will help us do two things:

1) It helps ensure that we do not artificially box ourselves in to a design just because there was something done similar or tangential in the past.

2) It helps ensure that we do not forget anything and ensures that we take advantage of lessons learned or really neat design elements from other work.

After this review phase we would work our way in to design where we will iron out all of the bumps and ridges and ensure that we are not creating a Frankenstein.  Some really cool designs may not be harmonious with our direction or other design elements. In those cases we need to pick and choose or redesign them.

There has been a lot of great work done here in the IETF, other SDOs, and industry in the past. We need to learn from that work and borrow great design elements from as many of them as we can.  But we also need to keep in mind that a complete solution to the problems identified in the CACAO Introduction draft is not currently available and there is no standardized solution used en mass by industry. Several vendors have their own solutions to this problem, but those only work within the confines of their products. We need to bridge the divide between treat hunters, threat defenders, vendor solutions, etc. This is the reason why we are working on this.  

Any work like this does require vast vendor adoption and buy-in and a lot of SMEs from industry. So as this work continues and grows, it is paramount that we engage with industry to help ensure that this works meets their requirements and that industry can and will adopt it. If they can not or will not adopt it, then we need to just stop work. There is no reason to create something that is not going to get adopted en mass. 

Thanks,
Bret

> On Sep 19, 2018, at 12:06 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello Carolin,
> 
> On Wed, Sep 19, 2018 at 10:26 AM <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Kathleen
> 
>  
> 
> The gap analysis may wind up just showing the gap, but I am hoping that there will be pieces of knowledge that can be gleaned from prior efforts.   Your authentication example is good.  There may be a need for it and the requirements may guide the selection of a solution that either works for both or that the new work has requirements (or technology evolved) that clearly show the need for something new.  
> 
> MILE protocols all support sharing formatted data, XML, JSON, etc. and are not restricted to IODEF.  There are 3 protocols to look at and I would hope that some could be reused, or that similar patterns may be useful.
> 
> Does that help?
> 
> Thanks,
> Kathleen
> 
> 
> 
>  
> 
> best regards
> 
> Carolin
> 
>  
> 
> From: Kathleen Moriarty [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Baumgartner Carolin <[email-masked] <mailto:[email-masked]>>
> Cc: Barry Greene <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Bret Jordan <[email-masked] <mailto:[email-masked]>>
> On Wed, Sep 19, 2018 at 4:31 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Bret, Kathleen
> 
>  
> 
> would that be something that could work as some kind of gap analysis? https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md <https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md> . It is no real gap analysis, this FAQ would rather highlight the differences. I just took two samples to show how that could look like and if that is what could be helpful. We could also include comments here like… "CACAO makes use of XY to achieve its goal".
> 
>  
> 
> best regards
> Carolin
> 
>  
> 
> From: Cacao [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
> To: Barry Greene <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Bret Jordan <[email-masked] <mailto:[email-masked]>>
> On Tue, Sep 18, 2018 at 6:35 PM Barry Greene <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Bret,
> 
>  
> 
> On Sep 18, 2018, at 23:49, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> All,
> 
>  
> 
> What device or system does the command target (DesktopOS 10 at IP address 10.0.0.2, Firewall BAR at 192.168.0..2)
> https://tools.ietf.org/html/rfc7970 <https://tools.ietf.org/html/rfc7970>
> https://tools.ietf.org/html/rfc8274#page-7 <https://tools.ietf.org/html/rfc8274#page-7>
>  
> 
> https://tools.ietf.org/html/rfc6545 <https://tools.ietf.org/html/rfc6545> 
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>
> -- 
> Cacao mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>
> 
>  
> 
> --
> 
>  
> 
> Best regards,
> 
> Kathleen
> 
> 
> 
>  
> 
> --
> 
>  
> 
> Best regards,
> 
> Kathleen
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen