[Ietf-calsify] Issue 80: security considerations section -- proposal

Bernard Desruisseaux bernard.desruisseaux at oracle.com
Wed Jun 13 06:38:53 PDT 2007


+1

Aki Niemi wrote:
> Hi all,
> 
> A while back, Jay posted an issue about the security considerations of 
> rfc2445bis, which is tracked as issue 80.
> 
> In one of the recent Jabber chats, I promised to take a stab at new text 
> for the section. Here's the proposal:
> 
> <section title='Security Considerations'>
> 
>   <p>
>     Because calendaring and scheduling information is very
>     privacy-sensitive, the protocol used for the transmission of
>     calendaring and scheduling information MUST have capabilities to
>     protect the information from possible threats, such as
>     eavesdropping, replay, message insertion, deletion, modification
>     and man-in-the-middle attacks.
>   </p>
> 
>   <p>
>     As this document only defines the data format and media type of
>     text/calendar that is independent of any calendar service or
>     protocol, it is up to the actual protocol specifications such as
>     <xref target="I-D.xxx">iTIP</xref>, <xref
>     target="I-D.xxx">iMIP</xref> and <xref
>     target="RFC4791">CalDAV</xref> to describe the threats that the
>     above attacks present, as well as ways in which to mitigate them.
>   </p>
> 
> In other words, rfc2445bis would now be completely silent about 
> authorization issues, and instead move responsibility over to actual 
> calendaring protocols and/or services. I'll note that a similar approach 
> has been taken in at least in RFC3863, Presence Information Data Format 
> (PIDF).
> 
> Any opinions?
> 
> Cheers,
> Aki
> (as individual contributor)
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


More information about the Ietf-calsify mailing list