Subject: [Ietf-calsify] Event class

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sun Aug 22 07:58:31 2004

Nathaniel,

In case you missed my reply on the subject, I suggested a definition for
each of these TYPEs.  In that message, I agreed with your conclusion
that confidential and private seem to mean the same thing.  My only
guess is that one represented personal confidentiality and the other
represented business-related confidentiality, and that the two flavors
might be filtered differently based on sophisticated ACLing.

I do think that the difference between public and private is somewhat
more clear - Outlook uses this notion to filter details of calendar
information, though it is not enforced as an access-level restriction.
It is purely client-implemented.

I do not think that this property has any real security surrounding it
in most applications.  In practice it is, as the RFC states, merely a
representation of the user's *intention*.  Correctly solving this
(privacy) concern requires digital signatures, encryption, and a
reliable PKI, not to mention some rather sophisticated semantics for
ACLing sub-schemas of the standard in question.

I think it is valuable to leave the details of this problem outside the
definition of the iCal format.  Clients and systems *can* require
cryptographically secure operations to transport iCalendars.  The fact
that they currently don't - is not necessarily a limitation of this
standard. S/MIME exists, therefore anything that can be expressed in
MIME can be transported with proper security controls applied and
transported without breaking the user's intention.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Saturday, August 21, 2004 4:11 PM
To: Satya Vempati
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Event class

On Aug 17, 2004, at 5:14 PM, Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
>
> The spec does not clearly define what each value means.

Yes, I'm puzzled on two levels.  First, what on Earth might have been
intended by the difference between PRIVATE and CONFIDENTIAL -- I
honestly don't even have a guess from reading the spec.  Second, what
are we really asserting when we mark something PRIVATE and then send it
around in an unencrypted email message?  The spec is actually explicitly
ambiguous:  "Hence, the semantics of the individual access
classifications cannot be completely defined by this memo alone."  What
the heck *can* define them?

This isn't just a pedantic question, because presumably any
implementation that differentiates between PUBLIC and PRIVATE is giving
the user some kind of indication/choice about the nature of the message,
and I rather doubt that the user expectations that might come from
choosing "PRIVATE" are satisfied by the typical implementation, let
alone by the results of interoperating between multiple systems.

In short, I question whether this distinction has any value at all, and
would be interested in knowing what it really means in implementations
that use it.  -- Nathaniel

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