Subject: [Cose] Stephen Farrell's Block on charter-ietf-cose-00-00: (with BLOCK and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 28 Apr 2015 07:30:33 -0700

Stephen Farrell has entered the following ballot position for
charter-ietf-cose-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cose/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I was initially skeptical of this work, doubting that
there is really sufficient real interest in CBOR to
justify spending the time on a WG. However, (just about)
enough people argued that they would or are using CBOR to
convince me that there could well be a real constituency
here. And given that, I'd prefer the work be done in the
IETF rather than ad-hoc and possibly by some folks who'd
prioritise constrained-system requirements too much over
security and privacy requirements. So in the end, I'm for
doing this.

I do have one blocking thing to discuss though, but that
should be easy enough as we mentioned it on the list
already and I think folks are ok with the sentiment and
we'll just need to get the right words. Anyway, my
blocking point is:

I think you need to add something to the effect that this
WG will not invent any new cryptography. (It is likely to
be asked to, since smaller-footprint is a requirement
that leads towards that.) I'd suggest adding "The COSE WG
will not innovate in terms of cryptography.  Any
algorithms to be used in COSE that are not already
well-established for use as part of some IETF standards
track specification will need to be checked via the CFRG
before being adopted here." I'm fine with other wordings,
what I wanted the above to allow was a bit more that just
what is already MTI in standards track RFCs, but to not
allow every single algorithm that has even gotten an IANA
code point somewhere to be just adopted as MTI by COSE.
And of course, for anything that is actually new to have to
go via CFRG first.

After we resolve this, I'll be balloting YES.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I think you could (and maybe should) lose all the
references to JOSE - this work involves re-doing all of
the same things, and won't be interoperable so I don't
see any value in re-use of registries to be honest. (And
maybe there is potential for minor confusion/harm there.)
I read the current text with all it's JOSE references as
trying to justify that the work is not just more JOSE
(both involve a lot of the same people), but at the same
time saying "this is like JOSE." And I don't think that
is needed - if there is real use of CBOR, then there will
be a real use of COSE. That doesn't depend on JOSE at
all, but more on whether folks see CBOR as being better
than JSON. The crypto primitives will just follow from
the application developer's chosen form of structured
encoding.

- The text assumes that ACE, DICE and CORE are already
bought into CBOR. I don't believe that is necessarily the
case, though I'd not be surprised if a bunch of folks
would argue for it to be the case.

- The milestone dates are nonsense. I'll buy the chairs a
beverage if they happen though. It is fine if folks want
to believe those dates though.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Apr 2015 08:32:37 -0700

On Apr 28, 2015, at 7:30 AM, Stephen Farrell <[email-masked]> wrote:
> I'd suggest adding "The COSE WG
> before being adopted here."

That idea sounds OK to me, but "well-established" is quite mushy, and it is not clear why COSE cannot describe the wire format for things that are in Experimental RFCs, since there is more push to go to Experimental for early IoT work. Also, some IETF WGs might be blocked by that wording. Further, you have already said on the COSE list that asking the CFRG is not always a good use of time.

How about:

The COSE WG will not innovate in terms of cryptography.  The specifiation of algorithms in COSE is limited to those in RFCs or active IETF WG documents.

> I'm fine with other wordings,

The question of mandatory-to-implement is quite different than specifying how to list something on the wire. Personally, I hope COSE has no MTI algorithms, and that MTI is defined by the specs that use the COSE format.

> And of course, for anything that is actually new to have to

I think the proposed wording above should cover that.

> After we resolve this, I'll be balloting YES.

Let us know if the proposal above resolves this.

I would be fine with that, but there were strong suggestions earlier that we had to justify "why not just use JOSE".

> bought into CBOR.

Bosh. The text suggests that there might be interest from those WGs, which we have seen. If some specific text "assumes" any of them have "bought in", we can remove it.

> I don't believe that is necessarily the

At some point, the IESG should agree whether new WGs should set milestones for what are supposed to be short-lived WGs "aggressively" or "based on historical precedent of WGs that didn't end when they should have". Until then, please don't ask forming WGs to read the IESG's mind. :-)

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 17:06:23 +0100

Hiya,

tl;dr - make that or an equivalent change and I'll s/block/yes/

On 28/04/15 16:32, Paul Hoffman wrote:
>> I'd suggest adding "The COSE WG will not innovate in terms of
>> cryptography.  Any algorithms to be used in COSE that are not
>> already well-established for use as part of some IETF standards 
>> track specification will need to be checked via the CFRG before
>> being adopted here."
> 
> That idea sounds OK to me, but "well-established" is quite mushy, and
> it is not clear why COSE cannot describe the wire format for things
> that are in Experimental RFCs, since there is more push to go to
> Experimental for early IoT work. Also, some IETF WGs might be blocked
> by that wording. 

All fair comment.

> Further, you have already said on the COSE list that
> asking the CFRG is not always a good use of time.
> 
> How about:
> 
> The COSE WG will not innovate in terms of cryptography.  The
> specifiation of algorithms in COSE is limited to those in RFCs or
> active IETF WG documents.

Yeah but... that would allow e.g. ibs [1] and ibake [2] and
other oddities that we probably don't want the WG to have to
bother with. Note: I'm not saying (here:-) either of those is
bad, nor that they'd be suggested here, they're just examples
of not-well-established algs that are ok according to the
above. (And full disclosure, I have a DISCUSS on [1] - afaik
there are no published analyses of it at all.)

But yes, the WG would of course almost certainly be
sensible and say "no thanks" if someone suggests those be
selected. I think some form of words that allows the WG to
not even bother having to discuss oddball stuff like that
would be better.

That said, I'm fine with unblocking and treating that as a
comment if your words (or similar) are added. We can try
improve that wording as we go along.

[1] https://tools.ietf.org/html/draft-ietf-manet-ibs-03
[2] https://tools.ietf.org/html/rfc6539

>> I'm fine with other wordings, what I wanted the above to allow was
>> a bit more that just what is already MTI in standards track RFCs,
>> but to not allow every single algorithm that has even gotten an
>> IANA code point somewhere to be just adopted as MTI by COSE.
> 
> The question of mandatory-to-implement is quite different than
> specifying how to list something on the wire. 

Yep. OTOH, if something is MTI in a standards track RFC then
that does kind of mean it's likely well-established. That's
all I was going after there but I also agree it's not a perfect
proxy for "well-established."

> Personally, I hope COSE
> has no MTI algorithms, and that MTI is defined by the specs that use
> the COSE format.

#include <usual-arguments.h> :-)

>> And of course, for anything that is actually new to have to go via
>> CFRG first.
> 

It resolves the block yes, but I'd still like better wording
if someone has some to offer.

>> references to JOSE - this work involves re-doing all of the same
>> things, and won't be interoperable so I don't see any value in
>> re-use of registries to be honest. (And maybe there is potential
>> for minor confusion/harm there.) I read the current text with all
>> it's JOSE references as trying to justify that the work is not just
>> more JOSE (both involve a lot of the same people), but at the same 
>> time saying "this is like JOSE." And I don't think that is needed -
>> if there is real use of CBOR, then there will be a real use of
>> COSE. That doesn't depend on JOSE at all, but more on whether folks
>> see CBOR as being better than JSON. The crypto primitives will just
>> follow from the application developer's chosen form of structured 
>> encoding.
> 
> I would be fine with that, but there were strong suggestions earlier
> that we had to justify "why not just use JOSE".

Sure, I can see that that was an issue. Maybe it's a thing of
the past now though? I'm not sure.

The point about pros and cons of shared registries though could
be worth some thought, so be good if the final charter doesn't
tie the WG's hands on that I reckon.

>> - The text assumes that ACE, DICE and CORE are already bought into
>> CBOR.
> 
> Bosh. The text suggests that there might be interest from those WGs,
> which we have seen. If some specific text "assumes" any of them have
> "bought in", we can remove it.

Well it does say that COSE is supposed to "fulfil[...] the needs of
those constituencies" which is a bit presumptuous as it does assume
that those WGs care about CBOR. I assume there's a missing "to
the extent relevant to their work" or some such.

>> I don't believe that is necessarily the case, though I'd not be
>> surprised if a bunch of folks would argue for it to be the case.
>> 
>> - The milestone dates are nonsense. I'll buy the chairs a beverage
>> if they happen though. It is fine if folks want to believe those
>> dates though.
> 
> At some point, the IESG should agree whether new WGs should set
> milestones for what are supposed to be short-lived WGs "aggressively"
> or "based on historical precedent of WGs that didn't end when they
> should have". Until then, please don't ask forming WGs to read the
> IESG's mind. :-)

The IESG does not have a mind. It has 15 regularly changing
minds:-)

Cheers,
S.

> 
> --Paul Hoffman _______________________________________________ Cose
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Apr 2015 09:27:15 -0700

> tl;dr - make that or an equivalent change and I'll s/block/yes/

Cool, thanks. I'm a bit embarrassed to admit that I don't know how to make a change to a proposed charter while it is in IESG evaluation. Does someone for the not-yet-WG do so? Or does the sponsoring AD do so?

> bother with.

The COSE WG doesn't *have* to bother with any particular crypto, and I suspect that a sane WG won't try to cover all types. After the COSE WG is done, as long as someone who cares about both Algorithm Foo and COSE can write their own specification, all is well. The same was true for CMS, OpenPGP, and so on.

> Note: I'm not saying (here:-) either of those is

There is a lot of crypto that most of us who are interested in COSE don't care about. 

> not even bother having to discuss oddball stuff like that

Hard to do that without being insulting. I think the current wording is fine, and if someone interprets the charter as to mean "must handle every possible algorithm", that's their issue.

> improve that wording as we go along.

Or they might never appear, just as they did not for various other wire-format WGs.

> if someone has some to offer.

Great.

> tie the WG's hands on that I reckon.

That's a good point, given that the not-yet-WG is already diverging from JOSE on "is a MAC a signature". I'd be fine with removing "COSE will rely on the JOSE registries, and will expand them with additional information when necessary" from the charter, even if the WG ends up wanting to do that.

--Paul Hoffman

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 28 Apr 2015 12:38:54 -0400

Sent from my iPhone

> On Apr 28, 2015, at 12:27 PM, Paul Hoffman <[email-masked]> wrote:
> 

I can do it, but it would be good to hear from more than one person and to see if there is better wording as requested.

Thanks,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 28 Apr 2015 14:28:15 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, April 28, 2015 7:31 AM
> To: The IESG
> Cc: [email-masked]
> Subject: [Cose] Stephen Farrell's Block on charter-ietf-cose-00-00: (with
> BLOCK and COMMENT)
> 
email
> addresses included in the To and CC lines. (Feel free to cut this
introductory
> paragraph, however.)
> I was initially skeptical of this work, doubting that there is really
sufficient real
> interest in CBOR to justify spending the time on a WG. However, (just
about)
> enough people argued that they would or are using CBOR to convince me that
> there could well be a real constituency here. And given that, I'd prefer
the
> work be done in the IETF rather than ad-hoc and possibly by some folks
who'd
> prioritise constrained-system requirements too much over security and
> privacy requirements. So in the end, I'm for doing this.
> 
> I do have one blocking thing to discuss though, but that should be easy
> enough as we mentioned it on the list already and I think folks are ok
with the
> sentiment and we'll just need to get the right words. Anyway, my blocking
> point is:
> 
> I think you need to add something to the effect that this WG will not
invent
> any new cryptography. (It is likely to be asked to, since
smaller-footprint is a
> requirement that leads towards that.) I'd suggest adding "The COSE WG will
> not innovate in terms of cryptography.  Any algorithms to be used in COSE
that
> are not already well-established for use as part of some IETF standards
track
> specification will need to be checked via the CFRG before being adopted
> here." I'm fine with other wordings, what I wanted the above to allow was
a bit
> more that just what is already MTI in standards track RFCs, but to not
allow
> every single algorithm that has even gotten an IANA code point somewhere
to
> be just adopted as MTI by COSE.
> And of course, for anything that is actually new to have to go via CFRG
first.

Stephen,

I am going to push back on this a bit.  The first question is what do you
mean by "new cryptography".    One of the algorithms mentioned on the list
was Pintsov-Vanstone Signatures with Message Recovery.  This was first
published at the latest of 1999 and appeared in IEEE P1363a (Jan 2000).   So
is an algorithm that has been around for on the order of 15 years "new
cryptography"?

Do you think it is better than a different working group - perhaps CORE-
did the innovation instead?  This language is not in the charter of any
other group that I am away of (think ACE?).  

What makes you think that the COSE working group would be any more likely to
do this that any other working group?

Jim

> - I think you could (and maybe should) lose all the references to JOSE -
this
> work involves re-doing all of the same things, and won't be interoperable
so I
> don't see any value in re-use of registries to be honest. (And maybe there
is
> potential for minor confusion/harm there.) I read the current text with
all it's
> JOSE references as trying to justify that the work is not just more JOSE
(both
> involve a lot of the same people), but at the same time saying "this is
like
> JOSE." And I don't think that is needed - if there is real use of CBOR,
then
> there will be a real use of COSE. That doesn't depend on JOSE at all, but
more
> on whether folks see CBOR as being better than JSON. The crypto primitives
> will just follow from the application developer's chosen form of
structured
> encoding.
> 
> - The text assumes that ACE, DICE and CORE are already bought into CBOR. I
> don't believe that is necessarily the case, though I'd not be surprised if
a
> bunch of folks would argue for it to be the case.
> 
> - The milestone dates are nonsense. I'll buy the chairs a beverage if they
> happen though. It is fine if folks want to believe those dates though.
> 
> 
> _______________________________________________
> Cose mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 22:40:43 +0100

Hiya,

> is an algorithm that has been around for on the order of 15 years "new

I mean new to the IETF and suggested "well established" (in the IETF)
as the qualifier. I don't think any signature scheme with recovery
would qualify as well established in the IETF, but I'm open to
correction there. And yes, some schemes have been known for many
years, but longevity by itself does not mean that either the IPR
situation is clear nor that there are not going to be either better
more modern schemes nor does it imply the absence of implementation
pitfalls that we have yet to discover which is quite possible if
a scheme has only really existed in the lab until now.

> do this that any other working group?

The code footprint requirement will lead to more requests for
unusual crypto. COSE is definitely going to be different in that
respect. I think that's already been seen on the list and your
example of message recovery is another indication that message
size issues will be different for COSE as well.

Cheers,
S.

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Apr 2015 22:20:07 +0000

Hi Stephen, Paul

On 2015-04-28 18:27, "Paul Hoffman" <[email-masked]> wrote:

>Cool, thanks. I'm a bit embarrassed to admit that I don't know how to
>make a change to a proposed charter while it is in IESG evaluation. Does
>someone for the not-yet-WG do so? Or does the sponsoring AD do so?
>
>The COSE WG doesn't *have* to bother with any particular crypto, and I
>suspect that a sane WG won't try to cover all types. After the COSE WG is
>done, as long as someone who cares about both Algorithm Foo and COSE can
>write their own specification, all is well. The same was true for CMS,
>OpenPGP, and so on.

I don’t understand how this formulation matches the conclusion in a
previous thread:

http://www.ietf.org/mail-archive/web/cose/current/msg00133.html

My interpretation of this previous thread is that COSE should compile
requirements for crypto needed and ask CFRG for recommendations. If CFRG
recommends algorithm X, why does it matter if it is an RFC or active IETF
WG document? If it does matter and if it isn’t, which WG should work on
this?

Thanks
Göran

>Hard to do that without being insulting. I think the current wording is
>fine, and if someone interprets the charter as to mean "must handle every
>possible algorithm", that's their issue.
>
>That's a good point, given that the not-yet-WG is already diverging from
>JOSE on "is a MAC a signature". I'd be fine with removing "COSE will rely
>on the JOSE registries, and will expand them with additional information
>when necessary" from the charter, even if the WG ends up wanting to do
>that.
>
>--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 23:25:33 +0100

Hiya,

On 28/04/15 23:20, Göran Selander wrote:
> requirements for crypto needed and ask CFRG for recommendations. 

If you'd said "new crypto" above, I'd agree that's a reasonable
thing. There's no need to ask CFRG if it's ok to use AES for
example and we know that COSE will define AES based things for
sure.

But characterising what is "new" and what to say about that in a
charter isn't trivial.

So I don't see any conflict between this discussion and that thread.

> If CFRG

I suspect that some people are (perhaps correctly) worried about how
that might impact on timelines too.

S.

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Apr 2015 23:05:14 +0000

Hi

>So I don't see any conflict between this discussion and that thread.

OK.

>that might impact on timelines too.

OK. But as was mentioned, I suppose there could be a modularity here so
that COSE is first applied with certain algorithms, and other algorithms
added later?

Going back to the formulation about referencing IETF documents: if it is
on one hand acknowledged that COSE algorithm requirements are allowed to
be different (minimize message size, code size, and computational
complexity), and on the other hand the specification of algorithms in COSE
is limited to those in RFCs or active IETF WG documents, then how are the
requirements going to be resolved within that charter?

Thanks
Göran

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Apr 2015 00:22:22 +0100

> requirements going to be resolved within that charter?

In practice I'd say there aren't that many points where this'll
be an issue, but there will be some. What I mean by "be an
issue" are cases where a WG really ought get advice from CFRG.

Signatures with message recovery as Jim mentioned is one, another
is likely to be a desire to specify an entire suite of crypto
mechanisms built around a single algorithm (so things like AES-CMAC)
to minimise footprint.

I don't think there are likely to be many more than that, or at
least not many more on which there'd be rough consensus to want
to do something even slightly novel, but who knows. There is I
suppose a reasonable probability that some folks will show up
who have radically different algorithms and who argue that those
ought be supported, and directing folks like that to CFRG can
also be useful.

So I'd say it shouldn't be too big a problem, especially if the
charter gives the WG ways to avoid heading off into the weeds.
But I do think it's quite likely the WG will want to do something
for which we really ought check with crypto folks.

So I think it's fairly clear what we want the charter to say,
getting the perfect wording for that might be tricky, but I'd say
that getting something good enough (like Paul H's wording) isn't
hard.

Cheers,
S.

---

From: Göran Selander <[email-masked]>
Date: Wed, 29 Apr 2015 04:04:24 +0000

Thanks Stephen. Your mail is very clear on what you support and what you
want to avoid. I just couldn’t read out things like support for
considering signatures with message recovery from the formulation of
limiting algorithms to RFCs etc.

Göran

---

From: Derek Atkins <[email-masked]>
Date: Wed, 29 Apr 2015 10:29:00 -0400

Stephen,

> a scheme has only really existed in the lab until now.

I still think this is a bit wishy-washy.  However I think using Paul's
suggested text is still a good starting point.  I agree that COSE should
not be "inventing crypto" however I do think that the COSE
specifications should be flexible enough to allow additional crypto
algorithms.

>> other group that I am away of A(think ACE?).  
>> 

As a purveyor of one such "unusual crypto", I just need to say that I
suspect the COSE specs to be frameworks with some well-known, suggested
algorithms (my guess: ECDSA, ECDH, AES-CTR-or-something, AES-CMAC) in
there for all the core operations.  But I also think that different
users of the COSE specs will need to (and SHOULD) be able to plug in the
algorithms (e.g. AEDH) that make the most sense to them for their
applications.  So we should enable that capability.

> S.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Apr 2015 15:49:35 +0100

Hiya,

I'm fine with all you say, but wanted to note one thing...

On 29/04/15 15:29, Derek Atkins wrote:
> As a purveyor of one such "unusual crypto"

Right. And you did the exactly right thing with that so far,
bringing it up in CFRG etc.

S.

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 29 Apr 2015 23:29:58 +0800

>I can do it, but it would be good to hear from more than one person and
>to see if there is better wording as requested.

I can help to consolidate the proposed changes and hopefully make it
easier for you. :-)

The proposed changes so far:

1) Add one paragraph below (proposed by Paul):
The COSE WG will not innovate in terms of cryptography.  The specifiation
of algorithms in COSE is limited to those in RFCs or active IETF WG
documents.

2) Remove one sentence below (proposed by Paul):
COSE will rely on the JOSE registries, and will expand them with
additional information when necessary.

3) Change one sentence below (proposed by Stephen)
OLD:
The working group will coordinate its progress with the ACE, DICE and CORE
working groups to ensure that we are fulfilling the needs of these
Constituencies.

NEW:
The working group will coordinate its progress with the ACE, DICE and CORE
working groups to ensure that we are fulfilling the needs of these
Constituencies to the extent relevant to their work.

Thanks,

Kind Regards
Kepeng

在 29/4/15 12:38 am， "Kathleen Moriarty" <[email-masked]>
写入:

>I can do it, but it would be good to hear from more than one person and
>to see if there is better wording as requested.
>
>Thanks,
>Kathleen

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 29 Apr 2015 23:41:15 +0800

> The milestone dates are nonsense. I'll buy the chairs a

I checked the other charters, usually they put one year between submitting
a document as WG item and submitting a document to the IESG.

Also we need a F2F meeting to discuss the drafts before adopting them, so
I propose to change June to July.

How about this:

OLD:
Jan 2016 Submit COSE constrained-appropriate algorithms to the IESG, for
publication as a Proposed Standard
Jan 2016 Submit COSE specification to the IESG, for publication as a
Proposed Standard
Jun 2015 Submit COSE constrained-appropriate algorithms as a WG item
Jun 2015 Submit COSE specification as a WG item

NEW:
Jul 2016 Submit COSE constrained-appropriate algorithms to the IESG, for
publication as a Proposed Standard
Jul 2016 Submit COSE specification to the IESG, for publication as a
Proposed Standard
Jul 2015 Submit COSE constrained-appropriate algorithms as a WG item
Jul 2015 Submit COSE specification as a WG item

Kind Regards
Kepeng

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 08:46:47 -0700

> Jul 2015 Submit COSE specification as a WG item

This was meant to be a short-lived WG for two focused items; it should not take a year to do this. Stephen might be right and we miss the goal of finishing this year, but I'd like to make him buy someone a beverage.

I also disagree that we need a F2F meeting on this at all. The mailing list is already working well on the early hard questions. If we can meet at an IETF meeting, great. If we need additional meetings, we can have a virtual interim. Please: let's not make this a "reason to travel" WG.

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Apr 2015 17:47:00 +0200

On 29 Apr 2015 at 17:42:13, Kepeng Li ([email-masked]) wrote:
I checked the other charters, usually they put one year between submitting 
a document as WG item and submitting a document to the IESG. 
We are not those other WGs.

Also we need a F2F meeting to discuss the drafts before adopting them, so 
I propose to change June to July. 
We do not need an F2F meeting for *adopting* a draft.

Can we please adopt Jim’s draft about a nanosecond after creating the WG?  We will have had enough time to determine whether this is a document that can substantially form the basis for the WG’s result (as in, yes).

(We also don’t need one for generating consensus on one to ship it to the IESG, but let’s see whether we do want to make use of Prague.)

Grüße, Carsten