Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Thu Feb 22 05:36:03 2007

[I've sent this issue to Bernard before the San Diego IETF]

> 3.8.4.7. Unique Identifier
>
> Property Name: UID
>
> Purpose: This property defines the persistent, globally unique
> identifier for the calendar component.

[...]

> Description: The "UID" itself MUST be a globally unique identifier.
> The generator of the identifier MUST guarantee that the identifier
> is unique. There are several algorithms that can be used to
> accomplish this. The identifier is RECOMMENDED to be the
> identical syntax to the [RFC2822] addr-spec.

The advice given in the last sentence seems reasonable, but when one
starts to look into addr-spec ABNF, one would find that the addr-spec
allows for folding whitespaces (FWS) in various place (and I don't think
use of FWS is a good idea in this case).
 From RFC 2822, section 3.4.1:

addr-spec = local-part "@" domain

local-part = dot-atom / quoted-string / obs-local-part

domain = dot-atom / domain-literal / obs-domain

domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent = dtext / quoted-pair

dtext = NO-WS-CTL / ; Non white space controls

%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"

where dot-atom is defined as:

dot-atom = [CFWS] dot-atom-text [CFWS]

obs-local-part and obs-domain also allow for FWS.

Suggestions:

Option 1) RECOMMEND using <id-left-strict>@<id-right-strict>, which are
defined as follows:

id-left-strict = dot-atom-text / no-fold-quote

id-right-strict = dot-atom-text / no-fold-literal / domain-literal-strict

domain-literal-strict = "[" *dcontent "]"

(all used non terminals come from RFC 2822)

Option 2) Keep the existing recommendation, but add a clarifying
statement that FWS or CFWS MUST NOT be used inside addr-spec.
Option 3) Reference the <mailbox> syntax in section 4.1.2 of RFC 2821
(SMTP), which defines:

Mailbox = Local-part "@" Domain

and doesn't allow for any extra folding whitespaces or RFC 2822 "comments".

====
My personal preference is option # 3. Bernard also likes # 3 and Cyrus
prefers # 2.

---

From: mgk at webfeet.co.uk (Martin Kiff)
Date: Thu Feb 22 07:40:55 2007

Alexey Melnikov wrote:

> The advice given in the last sentence seems reasonable...

Hummmm, but....

If you put an .ics file on the web, you've published a lot of email-like 
addresses; be prepared for them to be picked up by Spam-harvesters. I 
think the spec should suggest some other format.

Regards, Martin

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Thu Feb 22 07:46:53 2007

Martin Kiff wrote:

> If you put an .ics file on the web, you've published a lot of 
> email-like addresses; be prepared for them to be picked up by 
> Spam-harvesters.

So? They are not email addresses.

> I think the spec should suggest some other format.

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Feb 22 08:00:57 2007

Hi Martin,

> think the spec should suggest some other format.

The reality is a lot of clients tend to use a "GUID". We should probably 
add that as an alternative recommended format.

As to spam harvesting, its only the domain portion that is a valid "network 
address", and frankly that is likely to have much more exposure via email, 
so I would not be more concerned about having that in .ics data than the 
current state of affairs.

-- 
Cyrus Daboo

---

From: mgk at webfeet.co.uk (Martin Kiff)
Date: Thu Feb 22 22:53:05 2007

Cyrus Daboo wrote:

> Hi Martin,
>
> --On February 22, 2007 4:39:48 PM +0100 Martin Kiff 
> <[email-masked]> wrote:
>
> The reality is a lot of clients tend to use a "GUID". We should 
> probably add that as an alternative recommended format.
>
I think it would be better - or I've seen a URL referring to just that 
single event which keeps the transparency (GUID's would be opaque? There 
would be no way by eye to confirm that they are unique?) I think in DNS 
data the contacts are user-part.domain-part

> As to spam harvesting, its only the domain portion that is a valid 
> "network address", and frankly that is likely to have much more 
> exposure via email, so I would not be more concerned about having that 
> in .ics data than the current state of affairs.
>
Let's say, it is something I've seen in practice... messages bouncing 
off the spam defences sent to addresses taken from .ics files.

No, they wouldn't (shouldn't!) be real addresses but they load your ISP 
connection and add stress to your defences and it's a bit tough if you 
have a 'catch all' mailbox for your domain.

Regards, Martin

---

From: TimHare at comcast.net (Tim Hare)
Date: Fri Feb 23 04:41:26 2007

Here's a proposal for UID, although after I wrote it I'm not sure how
effective it would be against spam (it was written in a short time period).
Something along these lines could work, though; perhaps changing it to
(uniqueID)-hostname-domain where the '@' is removed?

Proposed Text for the UID property:

 Description:  The "UID" itself MUST be a globally unique identifier.
      The generator of the identifier MUST guarantee that the identifier
      is unique.  There are several algorithms that can be used to
      accomplish this.  The identifier is RECOMMENDED to be the
      identical syntax to the [RFC2822] addr-spec, however to avoid issues 
      with unsolicited e-mail ("spam"), a false hostname SHOULD be used.  A
good 
      method to assure uniqueness and security is to put a combination of
the 
      current calendar date and time of day (i.e., formatted as in a
DATE-TIME 
      value) along with some currently unique (perhaps sequential)
identifier 
      available on the system (for example a procss id number) on left-hand
side
      of the "@", and on the right hand side put a non-existent hostname
followed
      by the domain name or a domain literal IP address of the host on which
the
      identifier was created.   Using a date/time value on the left hand
side and
      a domain name or domain literal on the right hand side makes it
possible to
      guarantee uniqueness since no two hosts should be using the same
domain name
      or IP address at the same time. Using the non-existent hostname on the

      right-hand side allows the generator of the message identifier to
avoid 
      unsolicited e-mail easily. Though other algorithms will work, it is 
      RECOMMENDED that the right hand side contain some domain identifier
(either
      of the host itself or otherwise) such that the generator of the
message 
     identifier can guarantee the uniqueness of the left hand side within
the scope
     of that domain.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Kiff
Sent: Friday, February 23, 2007 1:52 AM
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the
UIDproperty

Cyrus Daboo wrote:

>> Spam-harvesters. I think the spec should suggest some other format.
>
>
I think it would be better - or I've seen a URL referring to just that
single event which keeps the transparency (GUID's would be opaque? There
would be no way by eye to confirm that they are unique?) I think in DNS data
the contacts are user-part.domain-part

> in .ics data than the current state of affairs.
Let's say, it is something I've seen in practice... messages bouncing off
the spam defences sent to addresses taken from .ics files.

No, they wouldn't (shouldn't!) be real addresses but they load your ISP
connection and add stress to your defences and it's a bit tough if you have
a 'catch all' mailbox for your domain.

Regards, Martin
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Feb 23 07:09:50 2007

Hi Tim,

--On February 23, 2007 7:38:37 AM -0500 Tim Hare <[email-masked]> 
wrote:

> effective it would be against spam (it was written in a short time
> period). Something along these lines could work, though; perhaps changing
> it to (uniqueID)-hostname-domain where the '@' is removed?
>
>
>
>
>       identical syntax to the [RFC2822] addr-spec, however to avoid
> issues        with unsolicited e-mail ("spam"), a false hostname SHOULD
> be used.  A good
>       available on the system (for example a procss id number) on
> left-hand side
>       by the domain name or a domain literal IP address of the host on
> which the

I think this is too much text for this "simple" property. I would like 
basically what we have now (with one of the 3 options Alexey proposed to 
clarify the "domain" syntax) together with the alternative of using a 
"GUID" (with a non-normative reference to the uuid algorithm in rfc4122). 
If "spam" is a concern then that should be mentioned in the security 
considerations. There should be a general security statement about exposing 
data "to the wild". Attendee addresses are likely to be much more of an 
issue than the domain-based UID.

A suggestion for a new Security Considerations sub-section:

PRIVACY:

iCalendar data is often made publicly available on the internet through 
some form of publishing or distribution service. In such cases, the authors 
of the data may prefer not to reveal information about themselves. If this 
is the case, the calendar components in the published calendar stream can 
use the "GUID" form for the UID property value, as opposed to the "domain" 
form, which can expose details about the creator's location etc. In 
addition, ORGANIZER and ATTENDEE properties contain personal addressing 
information that may need to be kept private. In that case, those 
properties can be removed from the published iCalendar data. Other 
properties that contain user supplied text could contain sensitive data - 
but for those it is up to the creator of the component to not add such data 
knowing that it will be published.

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Fri Feb 23 07:17:41 2007

In fact, can someone say to me why a change here isn't gratuitous?  Does 
anyone actually suffer with the existing text?

Eliot

Cyrus Daboo wrote:
> basically what we have now (with one of the 3 options Alexey proposed 
> to clarify the "domain" syntax) together with the alternative of using 
> a "GUID" (with a non-normative reference to the uuid algorithm in 
> rfc4122). If "spam" is a concern then that should be mentioned in the 
> security considerations. There should be a general security statement 
> about exposing data "to the wild". Attendee addresses are likely to be 
> much more of an issue than the domain-based UID.
>
> iCalendar data is often made publicly available on the internet 
> through some form of publishing or distribution service. In such 
> cases, the authors of the data may prefer not to reveal information 
> about themselves. If this is the case, the calendar components in the 
> published calendar stream can use the "GUID" form for the UID property 
> value, as opposed to the "domain" form, which can expose details about 
> the creator's location etc. In addition, ORGANIZER and ATTENDEE 
> properties contain personal addressing information that may need to be 
> kept private. In that case, those properties can be removed from the 
> published iCalendar data. Other properties that contain user supplied 
> text could contain sensitive data - but for those it is up to the 
> creator of the component to not add such data knowing that it will be 
> published.
>

---

From: lilmatt at mozilla.com (Matthew Willis)
Date: Fri Feb 23 09:09:06 2007

On Feb 22, 2007, at 10:39 AM, Martin Kiff wrote:

> If you put an .ics file on the web, you've published a lot of email- 
> like addresses; be prepared for them to be picked up by Spam- 
> harvesters. I think the spec should suggest some other format.

One could reverse the order.  ex: com.mozilla@lilmatt-GUID

We use GUIDs currently in Sunbird and Lightning, and I believe  
iCal.app uses them as well.  We should include that as an alternative  
format.

FWIW: We have had trouble dealing with the long GUIDs iCal.app uses,  
and folding them properly.

-lilmatt

---

From: mgk at webfeet.co.uk (Martin Kiff)
Date: Sat Feb 24 08:25:02 2007

Eliot Lear wrote:

> In fact, can someone say to me why a change here isn't gratuitous?  
> Does anyone actually suffer with the existing text?
>
> Eliot

For me, a change away from an 'obvious' email style address is not 
gratuitous. The original spec was written in more innocent times and as 
it stands it is _recommending_ something that is bad practice.

I suspect a minimal change would be OK based on the assumption that you 
are defending against naive address harvesters, ones which might not  be 
distinguishing between .html and .ics

I worry about suggesting alternatives; one which you might use 
internally and one externally, I thought the idea of the UID was that it 
uniquely identified the event so that the event had a one UID (and 
conversely however a calendar agent met it, if it had the same UID then 
it was talking about the same event).

Regards, Martin

---

From: lear at cisco.com (Eliot Lear)
Date: Sun Feb 25 11:03:48 2007

Martin,

What's the threat?  A domain name is not enough to be a threat.  Those 
are easily located, one way or another.  If you really want to be scared 
about this, we will need to find a way to obscure participant addresses.

Eliot