[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