Subject: [Ietf-calsify] Re: AD review on 2445bis

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Jun 2008 10:03:18 +0300

[CC'd the working group list]

Hi Lisa,

Overall, I think these comments fall into two categories; editorial and
substantial. I've labeled the issues below, and will start a new thread
on each substantial issue on the list.

AFAIK, none of the issues you mention have been brought up before. In
other words, good catches. ;)

Cheers,
Aki

to, 2008-05-29 kello 13:49 -0700, ext Lisa Dusseault kirjoitti:
> Section references:  Can we break section 3 down for publication?  It  
> would be so much easier to remember and refer to specific sections of  
> this document if we had section "4.4." be the UID parameter section  
> instead of 3.8.4.7.    My eyes just cross at the fourth level of  
> section nesting.  I am probably abnormally insistent about avoiding  
> that fourth hierarchy level, and you may all think I'm crazy to  
> suggest the work and change.  Nevertheless, I'll go ahead and suggest,  
> without any further pressure, a breakdown and ordering that I,  
> speaking as an individual and not as an AD (is that enough  
> disclaimers), would prefer:
> 	Section 3:   iCalendar Syntax
> 		Section 3.1: Content lines
> 		Section 3.2: Value Data Types
> 
> 	Section 4: ICalendar ojects and Components
>   		Section 4.1: iCalendar object
> 		Section 4.2: Components
> 
> 	Section 5: Properties
> 		Section 5.1: Property Parameters
> 		Section 5.2: Calendar Properties
> 		Section 5.3: Descriptive Component Properties
> 		Section 5.4: Date and Time Component Properties
> 		Section 5.5: Time Zone Component Properties
> 		Section 5.6: Relationship Component Properties
> 		Section 5.7: Recurrence Component Properties
> 		Section 5.8: Alarm Component Properties
> 		Section 5.9: Change Management Component Properties
> 		Section 5.10: Miscellaneous Component Properties
> 
> 	Section 6: iCalendar Object examples
> 
> 	... all further sections ++2

[editorial]

I think this change makes sense.

> Section -by-section comments:
> 
> Section 1: This sentence is really out of date/touch:
> 					However, the longer term growth of
>     calendaring and scheduling is currently limited by the lack of
>     Internet standards for the message content types that are central to
>     these knowledgeware applications.
> 
> I think we can just drop it unless you think there's something  
> important to preserve.

[editorial]

I agree.

> Section 3.2.1:
> The ALTREP parameter can be used in a lot of places.  I bet it's not  
> supported everywhere, and some usages of ALTREP could even be  
> dangerous.  Some health warnings should be added here at least.

[substantial]

I think this is also related to another issue listed below on
strengthening the security considerations section of the draft.

> Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs  
> only, if not by requirement then at least by noting that other types  
> of URLs are likely to be harmful to interoperability.

[substantial]

> Section 3.2.10: When a language tag can be used to distinguish between  
> multiple values, we do need a little guidance about how this is  
> intended to be used.  How is it used in practice?   Are clients  
> expected to display only the one that is their most preferred language  
> among the choices, or are clients expected to display all values and  
> use the language tag to help display properly?

[editorial]

I suspect this simply needs an implementation note on the subject.

> Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
> referenced is the SIBLING of this one?  How is a user agent supposed  
> to use this information?  Is this parameter ever used except on  
> RELATED-TO?  Is it actually in use even there?  Health warnings at  
> least.

[substantial]

> Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in  
> the same iCalendar document as VEVENTS?  A few years ago that was not  
> the case.  Can we now state that user agents SHOULD be able to handle  
> VTODOs as well as VEVENTS?

[substantial]

> Section 3.6.3: VJOURNAL: This needs a health warning even more than  
> VTODO does; some discussion about what users actually do with VJOURNAL  
> components, if ever, but nevertheless how preserving user data is  
> important...

[substantial]

> Section 3.8.1.10:  Is there some colloquial meaning of "raton- 
> laveur"?  A naive translation has this as "small rat washer"  and I'm  
> intrigued by why this would be a required resource for an event...  :)

[editorial]

Bernard? 

> Section 3.8.4.3, 3.8.4.4:   CONTACT and ORGANIZER and RECURRENCE-ID  
> are defined on VJOURNAL items.  I have no idea what they *mean* on  
> VJOURNAL.

[substantial]

> Section 3.8.8.2:  X- Properties:  We should recommend AGAINST using  
> these with user-readable strings like

I think there's some text missing here. Can you clarify?

> Section 5:  List item 2 is blank. So is #7.

[editorial]

> Section 7:  This is probably incomplete.  For example, there are  
> attacks with embedded HTML that are well-known, and could apply to any  
> usage of iCalendar.   Have we done brainstorming about other issues?

[substantial]

> Section 8:  It would help to add that we are now *updating* IANA  
> registries that were first established with RFC 2445.  (If we're not  
> making any changes, it would be good to say that instead).  IANA reads  
> this section mostly, and depends on this section to figure out what to  
> do...  Since these registries already exist, we can now put URLs in to  
> this document to be extra helpful to readers and to the IANA.

[editorial]

Good point.

Cheers,
Aki

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

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Jun 2008 12:56:14 +0300

> > dangerous.  Some health warnings should be added here at least.

I think we have a couple of options here. Either limit exactly on what
properties the parameter can occur out of the TEXT value type
properties. Or, keep it as it is currently defined. 

In any case, some text should be added to the security considerations.
Specifically, what attack vector did you have in mind?

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Jun 2008 12:59:12 +0300

> > of URLs are likely to be harmful to interoperability.

For maximum interoperability, a mandatory-to-implement choice should be
defined. However, is LDAP even widely enough supported in iCalendar
implementations to justify this? I suspect vCardDAV URLs could in the
future start appearing here as well.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Jun 2008 13:14:44 +0300

> > VTODOs as well as VEVENTS?

Isn't this the implicit assumption already? Namely that if an
implementation is conforming to the specification, it must supports all
of the defined components therein?

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Jun 2008 13:06:15 +0300

> > RELATED-TO?  Is it actually in use even there?  Health warnings at  

Good question. Is there a use case that requires a relationship beyond
parent-child (which currently is the only *defined* relationship in the
document anyway)?

Cheers,
Aki

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jun 2008 08:55:52 -0700

There are two issues here.  One is the attack vector, the other is  
interoperability combinatorial problems.

The attack vector we can do very little about without really breaking  
new ground in limiting where URLs can appear and what they can  
contain.  Even then, if some Rails Web application has URLs of the  
structure "http://calapp.example.org/lisa/e1234/delete" to mean  
"Delete the event ID 'e1234' on the 'lisa' calendar" -- and if the  
user has a cookie with a session giving them permissions to do this  
action -- there's not much a client application can reasonably do to  
detect that this might be a bad URL to go fetch.  (And a lot of the  
worst examples are cases of poor Web app design.)

The interoperability issue from combinatorial explosions of where you  
can find the ALTREP parameter and what can be in it, is not an attack  
-- it can happen innocently and even when an application is trying to  
do a creative extension to iCalendar.

One axis is the kind of URL you can see in ALTREP:  what would you do  
with

       DESCRIPTION;ALTREP="imap://[email-masked]/INBOX":The  
Fall'98 Wild
         Wizards Conference - - Las Vegas\, NV\, USA

The other axis is seeing ALTREP in places where even if the URL scheme  
is handled elsewhere in the client, it's unclear what it means in  
context:

         DUE;ALTREP="http://timezones.example.org/tz/America-Los_Angeles.ics 
":19980430T000000Z

I don't have good answers about what to do about this.  If we lock  
down what's allowed to a very narrow set of options, this limits  
extensibility.  That would also be a lot of work.

Would it be too much work to collect a list, not necessarily complete,  
of URL schemes that are used in ALTREP and a list of properties that  
they're seen on ?  Then an implementation note could simply say  
"Although the URL schemes used in ALTREP are not limited, in deployed  
implementations as of 2008 one tends to see only HTTP URLs.   
Similarly, although ALTREP can be used on any property, deployed  
implementations seem to use it  (dereference and/or display) only when  
it appears on the Comment, Description and Status properties, and the  
parameter is often ignored on other properties."

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jun 2008 09:01:07 -0700

> of the defined components therein?

I should add that currently VTODO and VJOURNAL are treated exactly the  
same way as far as requirements are concerned, even though real-world  
use of VTODO is much greater than for VJOURNAL and I'm not even sure  
we can explain how people use VJOURNAL.  So it seems odd that they're  
both assumed to be required but one is really used and the other is  
not.  That kind of thing may lead casual implementors to just ignore  
the implicit requirement, and lump VTODO in with VJOURNAL as something  
they don't really want to figure out how to support.

Again, I can't think of any new requirement that would be a definite  
good thing, but we could easily write an implementation note that  
mentions that VTODOs are increasingly seen in exported ICS files and  
even in iTIP messages and that VEVENTS are ubiquitous.

Lisa

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jun 2008 12:07:44 -0400

Hi Aki,

> future start appearing here as well.

I think at the very least HTTP/HTTPS needs to be allowed as well.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jun 2008 12:11:59 -0400

Hi Lisa,

--On June 16, 2008 9:01:07 AM -0700 Lisa Dusseault <[email-masked]> 
wrote:

> same way as far as requirements are concerned, even though real-world use
> of VTODO is much greater than for VJOURNAL and I'm not even sure we can
> explain how people use VJOURNAL.  So it seems odd that they're both
> assumed to be required but one is really used and the other is not.  That
> kind of thing may lead casual implementors to just ignore the implicit
> requirement, and lump VTODO in with VJOURNAL as something they don't
> really want to figure out how to support.
>
> Again, I can't think of any new requirement that would be a definite good
> thing, but we could easily write an implementation note that mentions
> that VTODOs are increasingly seen in exported ICS files and even in iTIP
> messages and that VEVENTS are ubiquitous.

I don't think we can require support of all components. I think it is 
perfectly fine for a "task management" application to only support VTODOs 
and still claim to be iCalendar compliant.

The suggestion of an implementation note that describes the "common use" of 
the components and explains that some may be supported and others not is 
fine. In fact telling implementors that they need to be prepared for 
another system to reject a component would be good.

-- 
Cyrus Daboo

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jun 2008 09:25:14 -0700

On Jun 16, 2008, at 9:11 AM, Cyrus Daboo wrote:

> Hi Lisa,
>
> --On June 16, 2008 9:01:07 AM -0700 Lisa Dusseault <[email-masked] 
> > wrote:
>
> I don't think we can require support of all components. I think it  
> is perfectly fine for a "task management" application to only  
> support VTODOs and still claim to be iCalendar compliant.
>
> The suggestion of an implementation note that describes the "common  
> use" of the components and explains that some may be supported and  
> others not is fine. In fact telling implementors that they need to  
> be prepared for another system to reject a component would be good.

I can get behind that.  I'd also like to recommend that systems not  
reject a component silently -- a user needs to know if they imported a  
iCalendar file and lost 50 VJOURNAL components in the process.

Lisa

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jun 2008 12:32:48 -0400

Hi Lisa,

> iCalendar file and lost 50 VJOURNAL components in the process.

Agreed.

Note that iTIP does have a status code for "Unsupported Component" (3.13) - 
so informing the originator of the iCalendar data that they are sending 
something that is not supported by the recipient is covered by that.

-- 
Cyrus Daboo

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 17 Jun 2008 12:47:40 -0400

As an "informed user" - i.e. not a developer, I definitely support
NON-silent rejection.  I can agree with non-support of certain components
only if I receive some notification;  due to work requirements I am now
journalling my time on some projects, and it would be good to know if I
can't import that data into another tool.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Monday, June 16, 2008 12:33 PM
To: Lisa Dusseault
Cc: [email-masked]; Bernard Desruisseaux
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

Hi Lisa,

--On June 16, 2008 9:25:14 AM -0700 Lisa Dusseault <[email-masked]>
wrote:

>> others not is fine. In fact telling implementors that they need to be 
>> prepared for another system to reject a component would be good.
>

Agreed.

--
Cyrus Daboo

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jun 2008 13:49:57 +0300

> worst examples are cases of poor Web app design.)

Right, I do agree there are a lot of things that bad web application
design is susceptible to here. But I don't see how this is especially
bad for iCalendar; it's simple enough to put URLs for images in an
HTML-formatted email, and achieve the same result. In fact, the
probablility of success in exploits this way is bound to be higher as
well (some mail applications actually follow the links).

> parameter is often ignored on other properties."

Do you mean summary not status? 

May I suggest an alternative approach? Since the list of "known" uses of
ALTREP can actually be narrowed down to about three, I think we should
add to the definition of each of these properties exactly what it means
to receive one with the ALTREP parameter that contains an HTTP URL.
Other URIs permitted, but their meaning is undefined. In other words,
document current practice as much as we can, but keep further uses open.

And then to ALTREP parameter, add the description you propose, as
generic advice to how the parameter should be handled/used.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jun 2008 13:50:45 +0300

> iCalendar file and lost 50 VJOURNAL components in the process.

That's a good point.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jun 2008 13:55:39 +0300

Continuing with the second batch of the AD review comments...

> > are defined on VJOURNAL items.  I have no idea what they *mean* on  

Can we safely remove VJOURNAL from the list of components for each of
these properties?

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jun 2008 14:09:44 +0300

> > usage of iCalendar.   Have we done brainstorming about other issues?

To my knowledge we have not. What might be helpful here are previous
examples of security considerations from similar work that could be used
as a basis. 

Cheers,
Aki

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 23 Jun 2008 09:22:23 -0700

> generic advice to how the parameter should be handled/used.

+1

---

From: Eliot Lear <[email-masked]>
Date: Sat, 28 Jun 2008 16:18:13 +0200

Am I correct in that this issue is to be resolved as below?  Are there 
any objections?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sat, 28 Jun 2008 16:19:20 +0200

I believe we have consensus as to Lisa's suggestion.  Any disagreement?

Eliot

Tim Hare wrote:
> --On June 16, 2008 9:25:14 AM -0700 Lisa Dusseault<[email-masked]>
> wrote:
>
>

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 28 Jun 2008 11:12:03 -0400

No disagreement from me. 

Tim Hare

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Saturday, June 28, 2008 10:19 AM
To: Tim Hare
Cc: 'Cyrus Daboo'; 'Lisa Dusseault'; [email-masked];
'Bernard Desruisseaux'

Eliot

Tim Hare wrote:
> NON-silent rejection.  I can agree with non-support of certain 
> components only if I receive some notification;  due to work 
> requirements I am now journalling my time on some projects, and it 
> would be good to know if I can't import that data into another tool.
>
>
> Tim Hare
> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in 
> thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review 
> on2445bis)
>
> Hi Lisa,
>
>> reject a component silently -- a user needs to know if they imported 
>> a iCalendar file and lost 50 VJOURNAL components in the process.
>>      
>
> Agreed.
>
> Note that iTIP does have a status code for "Unsupported Component" 
> (3.13) - so informing the originator of the iCalendar data that they 
> are sending something that is not supported by the recipient is covered by
that.

From: "Tim Hare" <[email-masked]>
To: "'Eliot Lear'" <[email-masked]>
Subject: RE: AD review issue #4: Supporting both VTODO and VEVENT in	thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review	on2445bis)
Date: Sat, 28 Jun 2008 11:12:03 -0400
Cc: [email-masked], 'Bernard Desruisseaux' <[email-masked]>

No disagreement from me. 

Tim Hare

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Saturday, June 28, 2008 10:19 AM
To: Tim Hare
Cc: 'Cyrus Daboo'; 'Lisa Dusseault'; [email-masked];
'Bernard Desruisseaux'

Eliot

Tim Hare wrote:
> NON-silent rejection.  I can agree with non-support of certain 
> components only if I receive some notification;  due to work 
> requirements I am now journalling my time on some projects, and it 
> would be good to know if I can't import that data into another tool.
>
>
> Tim Hare
> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in 
> thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review 
> on2445bis)
>
> Hi Lisa,
>
>> reject a component silently -- a user needs to know if they imported 
>> a iCalendar file and lost 50 VJOURNAL components in the process.
>>      
>
> Agreed.
>
> Note that iTIP does have a status code for "Unsupported Component" 
> (3.13) - so informing the originator of the iCalendar data that they 
> are sending something that is not supported by the recipient is covered by
that.

Date: Sat, 28 Jun 2008 16:19:20 +0200
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in	thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review	on2445bis)
Cc: [email-masked], 'Bernard Desruisseaux' <[email-masked]>

Eliot

> something that is not supported by the recipient is covered by that.

Date: Sat, 28 Jun 2008 16:18:13 +0200
From: Eliot Lear <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: [Ietf-calsify] Re: AD review issue #1: Use of ALTREP

Eliot

>> generic advice to how the parameter should be handled/used.

From: Lisa Dusseault <[email-masked]>
To: Aki Niemi <[email-masked]>
Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 23 Jun 2008 09:22:23 -0700
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

+1

Subject: Issue #6: Security Considerations (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 14:09:44 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

Subject: AD review issue #5: Meaning of Contact, Organizer and Recurrence ID in VJOURNAL (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:55:39 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:50:45 +0300
Cc: [email-masked], Bernard Desruisseaux <[email-masked]>

That's a good point.

Cheers,
Aki

Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:49:57 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

> > Specifically, what attack vector did you have in mind?

From: "Tim Hare" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>
Subject: RE: AD review issue #4: Supporting both VTODO and VEVENT in thesame	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)
Date: Tue, 17 Jun 2008 12:47:40 -0400
Cc: [email-masked], 'Bernard Desruisseaux' <[email-masked]>

Tim Hare

-----Original Message-----

Hi Lisa,

Agreed.

--
Cyrus Daboo

Date: Mon, 16 Jun 2008 12:32:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Cc: [email-masked], Bernard Desruisseaux <[email-masked]>

Hi Lisa,

Agreed.

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 09:25:14 -0700
Cc: [email-masked], Bernard Desruisseaux <[email-masked]>

Lisa

Date: Mon, 16 Jun 2008 12:11:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Aki Niemi <[email-masked]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Cc: [email-masked], Bernard Desruisseaux <[email-masked]>

Hi Lisa,

-- 
Cyrus Daboo

Date: Mon, 16 Jun 2008 12:07:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Aki Niemi <[email-masked]>, ext Lisa Dusseault <[email-masked]>
Subject: Re: AD review issue #2: DIR parameter (was: Re: [Ietf-calsify] Re: AD	review on 2445bis)
Cc: [email-masked], Bernard Desruisseaux <[email-masked]>

Hi Aki,

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
To: Aki Niemi <[email-masked]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 09:01:07 -0700
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Lisa

From: Lisa Dusseault <[email-masked]>
To: Aki Niemi <[email-masked]>
Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 08:55:52 -0700
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Lisa

> Specifically, what attack vector did you have in mind?

Subject: AD review issue #3: Meaning of RELTYPE parameter value of SIBLING (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 13:06:15 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

Subject: AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 13:14:44 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

Subject: AD review issue #2: DIR parameter (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 12:59:12 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

Subject: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 12:56:14 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>

Cheers,
Aki

From: Aki Niemi <[email-masked]>
To: ext Lisa Dusseault <[email-masked]>
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 10:03:18 +0300
Cc: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: [Ietf-calsify] Re: AD review on 2445bis

Hi Lisa,

Cheers,
Aki

[editorial]

[editorial]

I agree.

[substantial]

[substantial]

[editorial]

[substantial]

[substantial]

[substantial]

[editorial]

Bernard? 

[substantial]

[editorial]

[substantial]

[editorial]

Good point.

Cheers,
Aki

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 
Date: Mon, 9 Jun 2008 22:02:35 -0400

3.1 

"   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update/initial request or the "Attendee" sending a reply.  <<Or the
   person sending on their behalf? Clearly if somebody else is sending
   the invitation, she can't sign using the key belonging to the
   organizer>>"

This might impact ITIP and possibly iCal, but we may need a mechanism for an
Organizer to sign a security token when creating/authorizing a delegate, and
require that token to be present in anything sent on the Organizer's behalf.
This would be signed by the Organizer with the Organizer's private key, so
that it would be verifiable by decrypting it with the Organizer's public
key. I'm not a security expert, but it could be as simple as encrypting the
Organizer's RFC2822 address as the token and then upon decryption verifying
that it matched that of the Organizer.

After 3.5
 
"If an unsigned iMIP message is received from the same
   sender later on, the receiving CUA SHOULD warn the user about a
   possible man-in-the-middle attack and SHOULD ignore the message,
   unless explicitly overriden by the user. <<Should it also try to
   notify the other end?>>"

I would suggest that the answer to this question is "No", because if the
attacker has successfully interposed itself between the "other end" and this
CUA, any notification attempt would notify the attacker, allowing it to
withdraw and remove traces.

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 09, 2008 2:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Calendaring and Scheduling Standards
Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol
(iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-05.txt
	Pages		: 22
	Date		: 2008-6-9
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: [email-masked]
To: [email-masked]
Date: Mon,  9 Jun 2008 11:00:02 -0700 (PDT)
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-05.txt
	Pages		: 22
	Date		: 2008-6-9
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2447bis-05.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Tue, 03 Jun 2008 14:15:18 +0200
From: Eliot Lear <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] WGLC: draft-ietf-calsify-2446bis-06.txt && IETF Dublin
Cc: "[email-masked]" <[email-masked]>

Dear all,

This is a reminder that draft-ietf-calsify-2446bis-06.txt is in working 
group last call (WGLC).  Please submit any comments you have now.  Last 
call ends on June 15.

Eliot