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

[Aki Niemi]

Hi Oliver,

This is a point that has been discussed a lot. It is true that RFC2119 
text should only be used when there is an actual implementation choice 
that is observable from the outside. Here, I agree that a "MUST" is just 
hand-waiving, so I'm ok making it a "must" instead.

Cheers,
Aki

ext Oliver Block wrote:
> Hello Aki,
> 
> even though I like your proposal and to know that my calendar data is safe, Is 
> the MUST admissible in this context?
> 
> <copy src="rfc2119">
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> </copy>
> 
> Regards,
> 
> Oliver
> 
> Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
>> 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
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify