Subject: [Rats] Some info model comments

From: Laurence Lundblade <[email-masked]>
Date: Thu, 25 Jul 2019 19:23:52 -0400

Here’s a characterization of RATS work. The non-blue boxes are where I believe RATS work is. 

The proposed information model draft does two things that I think are problem.

First, it tries to span the orange and yellow boxes. These boxes are super different. I don’t think they should be mixed in one model. The yellow boxes are general claims about the entities. The orange box is inputs and outputs related to TPMs. For example, instructions to TPMs to do one type of attestation or another type.

Second, it cut the definition of a claim in two. Part of it would go in the information model and another part of it would go in the EAT draft or such. When you tweak the definition of a claim, say the location claim, you might have to update one document, the other, or both.

I can think of ways to make use of info/data models in productive ways for RATs, but they would be different than the proposal. Something like this:

There would be one info model for claims and another for transport. Maybe a little fudging for the nonce, but it is simple and well understood.

The definition of a particular claim would be in only one document. It’s OK if there are common data types uses by claims are in a separate document (kind of like a .h file). 

LL

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Fri, 26 Jul 2019 07:02:48 +0000

I support this proposal. I too am a little confused that TPM attestation structures are treated differently from the proposed EAT-tyle.

In our thinking, the TPM-constrainted attestation (TPM2_ATTEST, aka. TPM2 quote) is a subtype of a more generic EAT structure.

At least this is how we see it

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: 26 July 2019 02:23
To: [email-masked] <[email-masked]>
Subject: [Rats] Some info model comments

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Jul 2019 11:09:52 -0400

Hi Ian,

My TPM knowledge is limited, but I think it goes like this:
   Payload / claims: EAT and TPM are very different and incompatible
   Signing format: EAT and TPM are very different and incompatible
   Proposed as part of remote attestation standard in RATS Work Group: identical
   Transportable by YANG-described protocols like NetConf and COAP: near identical
   Transportable in extensions of protocols like FIDO: near identical

I don’t think there’s any useful way to achieve much more compatibility with the first two points, so I’m not sure what “subtype” would mean if you are talking about data structures in some formal or semi-formal way.

Maybe you are suggesting that all the attestation tokens standardized by RATS should be named an EAT?

LL

> On Jul 26, 2019, at 3:02 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
>

---

From: Carl Wallace <[email-masked]>
Date: Fri, 26 Jul 2019 08:18:32 -0700

Seems you could define a claim carried in an EAT that encapsulated existing attestation types. 

> On Jul 26, 2019, at 8:09 AM, Laurence Lundblade <[email-masked]> wrote:
> 
> Hi Ian,
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Fri, 26 Jul 2019 15:47:11 +0000

<quote>
</quote>

We already deal with a number of different kinds of attestation information, eg: from a TPM, from a CPU enclave, from a VM image/instance etc. There's a lot of commonality in the structure and often in the content. Would it therefore not make sense to use the EAT as that generic structure?  At least, this is my understanding. We're not going to get rid of TPM and its structures and I'm a little confused why there exists this difference here?

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: 26 July 2019 18:09
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Rats] Some info model comments

Hi Ian,

LL

On Jul 26, 2019, at 3:02 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:

Ian

________________________________
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: 26 July 2019 02:23
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Rats] Some info model comments

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Jul 2019 11:47:39 -0400

We could certainly come up with CBOR and JSON to carry a TPM2 quote and such. 

My reading of CWT is that it is always wrapped by COSE and always signed and thus EAT is always signed. If we were to put a TPM2 quote in a CWT/EAT, it would have to be signed. Seems like there a few options here:
Somehow make signing optional for EAT.
Allows some sort of NULL signing or MAC with some sort of NULL key
Use the TPM to sign causing the claims payload to be double-signed. The second signing wouldn’t add much security, but it might be better than NULL signing
Do not encapsulate
Define a type / claim that is used only in when nesting a TPM2 quote in a signed EAT. This is a special case of the nesting that is already defined in EAT.
I don’t like the first one much because it diverges EAT and CWT. The middle three seem about equal to me.The last seems useful and proper for a complete definition of EAT that is harmony with all of RATS.

LL

> On Jul 26, 2019, at 11:18 AM, Carl Wallace <[email-masked]> wrote:
> 
> On Jul 26, 2019, at 8:09 AM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Ian,
>> 
>>> On Jul 26, 2019, at 3:02 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>>> Sent: 26 July 2019 02:23
>>> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 26 Jul 2019 11:54:25 -0400

Hi Laurence and Ian,

The working consensus within the TCG attestation community is that:

(1) For TPM 1.2, you can use signed Quote
(2) For TPM 2.0, signed Quote is insufficient
(2b) For TPM 2.0, you can use a signed Audit Session (a superset of Quote)

So it would be good not to reference TPM 2.0 Quote as the payload in this
discussion.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jul 26, 2019 at 11:47 AM Laurence Lundblade <[email-masked]>
wrote:

> My reading of CWT is that it is always wrapped by COSE and always signed
> and thus EAT is always signed. If we were to put a TPM2 quote in a CWT/EAT,
> it would have to be signed. Seems like there a few options here:
>
>    - Somehow make signing optional for EAT.
>    - Allows some sort of NULL signing or MAC with some sort of NULL key
>    - Use the TPM to sign causing the claims payload to be double-signed.
>    The second signing wouldn’t add much security, but it might be better than
>    NULL signing
>    - Do not encapsulate
>    - Define a type / claim that is used only in when nesting a TPM2 quote
>    in a signed EAT. This is a special case of the nesting that is already
>    defined in EAT.
>
> I don’t like the first one much because it diverges EAT and CWT. The
> middle three seem about equal to me.The last seems useful and proper for a
> complete definition of EAT that is harmony with all of RATS.
>
> LL
>
>
>    *Payload / claims:* EAT and TPM are very different and incompatible
>    *Signing format:* EAT and TPM are very different and incompatible
>    *Proposed as part of remote attestation standard in RATS Work Group:*
> identical
>    *Transportable by YANG-described protocols like NetConf and COAP: *near
> identical
>    *Transportable in extensions of protocols like FIDO: *near identical
>
> I don’t think there’s any useful way to achieve much more compatibility
> with the first two points, so I’m not sure what “subtype” would mean if you
> are talking about data structures in some formal or semi-formal way.
>
> I support this proposal. I too am a little confused that TPM attestation
> structures are treated differently from the proposed EAT-tyle.
>
> In our thinking, the TPM-constrainted attestation (TPM2_ATTEST, aka. TPM2
> quote) is a subtype of a more generic EAT structure.
>
> ------------------------------
> *From:* Laurence Lundblade <[email-masked]>
> *Sent:* 26 July 2019 02:23
> *To:* [email-masked] <[email-masked]>
> *Subject:* [Rats] Some info model comments
>
> First, it tries to span the orange and yellow boxes. These boxes are super
> different. I don’t think they should be mixed in one model. The yellow
> boxes are general claims about the entities. The orange box is inputs and
> outputs related to TPMs. For example, instructions to TPMs to do one type
> of attestation or another type.
>
> Second, it cut the definition of a claim in two. Part of it would go in
> the information model and another part of it would go in the EAT draft or
> such. When you tweak the definition of a claim, say the location claim, you
> might have to update one document, the other, or both.
>
> I can think of ways to make use of info/data models in productive ways for
> RATs, but they would be different than the proposal. Something like this:
>
> There would be one info model for claims and another for transport. Maybe
> a little fudging for the nonce, but it is simple and well understood.
>
> The definition of a particular claim would be in only one document. It’s
> OK if there are common data types uses by claims are in a separate document
> (kind of like a .h file).
>
>
>
> LL
>
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 26 Jul 2019 17:56:44 +0200

It would be possible to take a TPM structure (that is the output of a 
TPM command and typically includes a signature) and put it into an EAT 
claim value.

If there is a use case where a bundle of TPM structures other claims are 
conveyed, signing the EAT could make sense in same cases, I think, 
because it might add some (in this case still hypothetical) value.

If remote attestation is based solely on already signed TPM structures, 
maybe bundling them in an EAT still could be useful, but signing that 
bundle would not add value, I think.

That is why TUDA is working the other way around.

If a TPM is used in TUDA, the native structure is decomposed down to its 
values on the sender side, put into a very concise CBOR structure that 
is far smaller than the native structure, is then conveyed, and then 
canonically reconstructed as a valid signed TPM structure on the 
receiver side.

Additionally, any values that can be omitted because the receiver would 
already know these values or could deterministically infer them in a 
TUDA procedure are omitted in the conveyed CBOR structure - making it 
even more compact/compressed.

That is the reason why TUDA is not using EAT, if a TPM is involved. If a 
TA in a TEE would provide the respective root-of-trust services, EAT 
could be used in that TUDA flavor - and actually would be my first and 
most obvious choice :)

Viele Grüße,

Henk

On 7/26/19 5:18 PM, Carl Wallace wrote:
>> *Transportable by YANG-described protocols like NetConf and COAP: 
>> *near identical
>> I don’t think there’s any useful way to achieve much more 
>> compatibility with the first two points, so I’m not sure what 
>> “subtype” would mean if you are talking about data structures in some 
>> formal or semi-formal way.
>>
>>> On Jul 26, 2019, at 3:02 AM, Oliver, Ian (Nokia - FI/Espoo) 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> I support this proposal. I too am a little confused that TPM 
>>> attestation structures are treated differently from the proposed 
>>> EAT-tyle.
>>>
>>> In our thinking, the TPM-constrainted attestation (TPM2_ATTEST, aka. 
>>> TPM2 quote) is a subtype of a more generic EAT structure.
>>>
>>> ------------------------------------------------------------------------
>>> *From:*Laurence Lundblade <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Sent:*26 July 2019 02:23
>>> *To:[email-masked] <mailto:[email-masked]> <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Subject:*[Rats] Some info model comments
>>>     First, it tries to span the orange and yellow boxes. These boxes
>>>     are super different. I don’t think they should be mixed in one
>>>     model. The yellow boxes are general claims about the entities.
>>>     The orange box is inputs and outputs related to TPMs. For
>>>     example, instructions to TPMs to do one type of attestation or
>>>     another type.
>>>
>>>     Second, it cut the definition of a claim in two. Part of it would
>>>     go in the information model and another part of it would go in
>>>     the EAT draft or such. When you tweak the definition of a claim,
>>>     say the location claim, you might have to update one document,
>>>     the other, or both.
>>>
>>> I can think of ways to make use of info/data models in productive 
>>> ways for RATs, but they would be different than the proposal. 
>>> Something like this:
>>>
>>>     There would be one info model for claims and another for
>>>     transport. Maybe a little fudging for the nonce, but it is simple
>>>     and well understood.
>>>
>>>     The definition of a particular claim would be in only one
>>>     document. It’s OK if there are common data types uses by claims
>>>     are in a separate document (kind of like a .h file). 
>>>
>>>
>>>
>>> LL
>>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Jul 2019 12:08:27 -0400

Hmm, still can’t tell if you are just talking about naming or about the format of serialized bits on the wire.

To comment on serialized bits on the wire — the TPM formats are locked down and the RATS WG has no chance of changing them. They are however not very modern or flexible so we don’t want to use them where we don’t need to use them. CWT and COSE already exist and are just about ideal as a modern flexible format. Thus we end up with (at least) two largely incompatible formats in RATs.

To go on a bit further and think about the future — I would hope that the TPM (or other HW) of the future (5-10 years out) would use the CWT / COSE format. I have thought some about whether CWT / COSE could be implemented in HW and do think it is possible. In particular CBOR supports indefinite length encoding for maps, arrays and strings. It also supports encoding modes for integers that are easy to do in hardware (e.g. when compared to JSON or ASN.1).  It is a goal of the EAT draft that HW implementations be possible. This is reason for a lot of text here <https://tools.ietf.org/html/draft-ietf-rats-eat-01#section-4.4.2>. (If there is ever a rev of CWT the RFC, this should be added to it IMO). 

LL

> On Jul 26, 2019, at 11:47 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
> 
> <quote>

---

From: Carl Wallace <[email-masked]>
Date: Fri, 26 Jul 2019 09:38:31 -0700

Your last bullet is what I was thinking. 

> On Jul 26, 2019, at 8:47 AM, Laurence Lundblade <[email-masked]> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 26 Jul 2019 19:03:17 +0200

It is important to take into account the types of constraints in a 
constraint-node environment. If you really want to reduce message size, 
adding a wrapper (e.g. CWT) or a not required (potentially NULL) 
signature is not necessarily the thing you want to do.

That said, for the reason to be more uniform and interoperable your 
fifth point should always be a valid option and it should be a 
well-phrased EAT profile, I think.

As with TUDA, sometimes you need not to encapsulate but go into the 
opposite direction to reduce message size - that should also always be a 
valid option, I think.

While the normative text in CWT is a bit curious, I think section 7 in 
rfc8392 makes it pretty clear that an CWT should always be "signed, 
MACed, or encrypted". And we should not mess with that :)

Viele Grüße,

Henk

On 7/26/19 6:38 PM, Carl Wallace wrote:
> On Jul 26, 2019, at 8:47 AM, Laurence Lundblade <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> My reading of CWT is that it is always wrapped by COSE and always 
>> signed and thus EAT is always signed. If we were to put a TPM2 quote 
>> in a CWT/EAT, it would have to be signed. Seems like there a few 
>> options here:
>>
>>   * Somehow make signing optional for EAT.
>>   * Allows some sort of NULL signing or MAC with some sort of NULL key
>>   * Use the TPM to sign causing the claims payload to be
>>     double-signed. The second signing wouldn’t add much security, but
>>     it might be better than NULL signing
>>   * Do not encapsulate
>>   * Define a type / claim that is used only in when nesting a TPM2
>>     quote in a signed EAT. This is a special case of the nesting that
>>     is already defined in EAT.
>>
>> middle three seem about equal to me.The last seems useful and proper 
>> for a complete definition of EAT that is harmony with all of RATS.
>>
>> LL
>>
>>
>>> On Jul 26, 2019, at 11:18 AM, Carl Wallace <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> On Jul 26, 2019, at 8:09 AM, Laurence Lundblade 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>> Hi Ian,
>>>>
>>>> *Proposed as part of remote attestation standard in RATS Work 
>>>> Group:* identical
>>>> “subtype” would mean if you are talking about data structures in 
>>>> some formal or semi-formal way.
>>>>
>>>> Maybe you are suggesting that all the attestation tokens 
>>>> standardized by RATS should be named an EAT?
>>>>
>>>> LL
>>>>
>>>>
>>>>
>>>>> <mailto:ian.oliver@nokia-bell-labs..com>> wrote:
>>>>>
>>>>> In our thinking, the TPM-constrainted attestation (TPM2_ATTEST, 
>>>>> aka. TPM2 quote) is a subtype of a more generic EAT structure.
>>>>>
>>>>>     First, it tries to span the orange and yellow boxes. These
>>>>>     boxes are super different. I don’t think they should be mixed
>>>>>     in one model. The yellow boxes are general claims about the
>>>>>     entities. The orange box is inputs and outputs related to TPMs.
>>>>>     For example, instructions to TPMs to do one type of attestation
>>>>>     or another type.
>>>>>
>>>>>     Second, it cut the definition of a claim in two. Part of it
>>>>>     would go in the information model and another part of it would
>>>>>     go in the EAT draft or such. When you tweak the definition of a
>>>>>     claim, say the location claim, you might have to update one
>>>>>     document, the other, or both.
>>>>>
>>>>>     transport. Maybe a little fudging for the nonce, but it is
>>>>>     simple and well understood.
>>>>>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 26 Jul 2019 17:41:56 +0000

My example (I’m sure there are others) in the third category is called “OPC UA” https://en.wikipedia.org/wiki/OPC_Unified_Architecture
It’s the most widely deployed IP-based protocol in industrial IoT.  OPC UA is used to talk to controllers that use  various fieldbus protocols
(https://en.wikipedia.org/wiki/Fieldbus) to talk to actual equipment).

As correctly noted in the “UA Security” section of wikipedia, “The authentication uses X.509<https://en.wikipedia.org/wiki/X.509> certificates exclusively. It relies on the
application developer to choose which certificate store the UA application gets bound to.”  So choosing a “certificate store” that
supports whatever X.509 attestation stuff RATS might define should work.

Dave

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Thursday, July 25, 2019 7:24 PM
To: [email-masked]
Subject: [Rats] Some info model comments

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 29 Jul 2019 19:39:40 +0000

If the RATS IM assumes claims are always signed, then the question must be asked *when* is it allowed for claims to be unsigned during their construction? The IM therefore must anticipate unsigned claims in order to describe, at least, the construction phase.

Additionally, for performance optimization reasons, it makes sense to bundle or group claims within a *collection* of claims that are signed together. Otherwise, an implementer might assume each claim should be signed individually and immediately (which isn’t practical). Therefore, intuitively the IM will support grouping of unsigned claims at least during the collection step.

In a TEEP use case context, there could be several TA (TEEs) endpoints on the same device/platform/entity each of which could in theory produce an attestation (group of signed claims). Nevertheless, the attester (endpoint that holds the connection to the Verifier) collects local TA attestations and assembles them somehow into another layer of claims. The question to consider is whether another layer of signatures is needed since the TA attestations are already signed (presumably) and whether or not the Verifier supplied nonce needs to be included in the TA signed attestations or is including the nonce in the top level grouping sufficient? There are performance-security trade-off considerations here.

The threads involving alternative signing formats (e.g. OPC-UA aka X.509/BER or TPM which may be categorized as a binary encoding) suggests the RATS IM should be able to encapsulate already signed objects (claims?) that are encoded differently from other signed objects.

An important RATS IM design consideration is whether or not there is a “top level” encapsulation that must always be signed according to a particular signing convention (e.g. COSE) or can it support, for example, OPC-UA conventions where signatures must be BER encoded (assuming I’m understanding Dave Thaler’s other thread on how OPC-UA works)?

In summary, it seems reasonable for an IM that can talk about:

i)                    individual claims as unsigned expressions where the semantics are clear

ii)                   groupings of unsigned claims

iii)                 signed claims

iv)                 groupings of signed claims that are unsigned

v)                   groupings of signed claims that are signed (maybe expand to grouping of both signed and unsigned claims?)

vi)                 groupings of signed claims that are formatted differently from a parent or child grouping of signed claims

There may be other cases, but this seems like a reasonable set to consider initially.

-Ned

On 7/26/19, 8:55 AM, "RATS on behalf of Ira McDonald" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence and Ian,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Jul 26, 2019 at 11:47 AM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
We could certainly come up with CBOR and JSON to carry a TPM2 quote and such.

My reading of CWT is that it is always wrapped by COSE and always signed and thus EAT is always signed. If we were to put a TPM2 quote in a CWT/EAT, it would have to be signed. Seems like there a few options here:
· Somehow make signing optional for EAT.
· Allows some sort of NULL signing or MAC with some sort of NULL key
· Use the TPM to sign causing the claims payload to be double-signed. The second signing wouldn’t add much security, but it might be better than NULL signing
· Do not encapsulate
· Define a type / claim that is used only in when nesting a TPM2 quote in a signed EAT. This is a special case of the nesting that is already defined in EAT.
I don’t like the first one much because it diverges EAT and CWT. The middle three seem about equal to me.The last seems useful and proper for a complete definition of EAT that is harmony with all of RATS.

LL

On Jul 26, 2019, at 11:18 AM, Carl Wallace <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 26, 2019, at 8:09 AM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian,

LL

Ian

First, it tries to span the orange and yellow boxes. These boxes are super different. I don’t think they should be mixed in one model.. The yellow boxes are general claims about the entities. The orange box is inputs and outputs related to TPMs. For example, instructions to TPMs to do one type of attestation or another type.

LL

_______________________________________________
RATS mailing list
RATS@ietf..org<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 30 Jul 2019 17:07:20 +0200

If remote attestation is based solely on already signed TPM structures, 
maybe bundling them in an EAT still could be useful, but signing that 
bundle would not add value, I think. Analogously, I am not convinced 
that null ciphers, etc. are the bests approach here - and CWT need to 
use COSE.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 30 Jul 2019 17:08:20 +0200

oops. Sry, for double posting, days old open window.

Cheers,

Henk

-------- Forwarded Message --------
Subject: Re: [Rats] Some info model comments
Date: Tue, 30 Jul 2019 17:07:20 +0200
From: Henk Birkholz <[email-masked]>
To: [email-masked]

Viele Grüße,

Henk