Subject: Poll: What goes in...

From: [email-masked]
Date: Tue, 4 Jan 2000 11:15:58 -0500

must come out?  During some of the hallway converstations in DC I got into 
a discussion w/others about data preservation and integrity.  Some folks 
think that the data you put into the CS does not have to come back out 
"intact".  (By "intact" I do not mean byte for byte exact unless necessary 
for stuff like multipart/signed or multipart/encrypted.)  After some 
heated back and forth we reset the talk and I tried to learn more about 
their POV.  I think after a nights sleep we were able to pick up the 
discussion but I left somewhat dazed on this issue.

So Im taking a poll of the list to see what others expect from their CS. 
Should the CS return to you the equivalent MIME data that the CUA put into 
it?  The 8 possible cases to consider:

Usigned, unencrypted entries (no outter MIME wrappers):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Signed, unencrypted entries (outter multipart/signed MIME wrapper):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Unsigned, Encrypted entries (outter multipart/encrypted MIME wrapper):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Signed, Encrypted entries (outter multipart/signed and multipart/encrypted 
MIME wrappers):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)

What Im want to poll the group on is what is the CS's expected behaviour 
WRT 2.x, 3.x and 4.x cases.  Ill focus on the 2.x cases for the rest of 
this posting...

Some have claimed that the CS does not have to preserve the signature of 
the original data.  They expect the CS to 'rebuild' the entry for the CUA 
from what ever internal format it uses and send back an equivalent 2.1 or 
2.2 style entry but it would have the CS's signature instead of the 
original one.  Paul (B. Hill) stated that 'audit trails' of signatures is 
not a CAP requirement but when I look in the version on the WG site I dont 
see it mentioned either way.  So I thought Id poll the group and see what 
they expect/thought WRT this issue.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Jan 2000 12:06:51 -0800

[email-masked] wrote:
> 
> must come out?  During some of the hallway converstations in DC I got into a
> discussion w/others about data preservation and integrity.  Some folks think
> that the data you put into the CS does not have to come back out "intact".
>  (By "intact" I do not mean byte for byte exact unless necessary for stuff
> like multipart/signed or multipart/encrypted.)  After some heated back and
> forth we reset the talk and I tried to learn more about their POV.  I think
> after a nights sleep we were able to pick up the discussion but I left
> somewhat dazed on this issue.
> 
> ....

>      not a CAP requirement but when I look in the version on the WG site I
>      dont see it mentioned either way.  So I thought Id poll the group and see
>      what they expect/thought WRT this issue.

The CS is not a tape archive. It can manipulate the data, other users
can update the data. It can represent the data differently. I recall
a conversation where one vendor wanted to unwind some RRULEs when
they pulled it out (REPEAT 5 days -> 5 unique DATE entries).

In the EMAIL world a signature not only means that you sent the email,
it verifies that this is the email you sent. I don't know of any way
to preserve this information. If nothing else, the instant that the
CUA deposits this information into the CS the LAST-MODIFIED date will
change. Now what the original user sent is not the same as what is
in the CS == signaure invalid.

I also recall the DC hallway conversation saying that audit trails are
out of scope for CAP. And that seems to be the only reason for the
signature once it is verified and deposited into a CS.

There was conversation about preserving the signature so that it was
valid across the wire. This as I recall involved rearranging the
V{...} blocks so it could be done. (Anyone else remember?)

---

From: David Madeo <[email-masked]>
Date: Fri, 14 Jan 2000 12:51:25 -0500

> they pulled it out (REPEAT 5 days -> 5 unique DATE entries).

As a customer, I can safely say that I'd like to be able to import
everything related to a calendar store (calendars, ACL's, etc).  I'd
also like to export that same set of things that I can import.  It
should be completely bi-directional.  Do not trap me in an
implementation or think that it's ok to ask the user to re-enter data.

While I agree that users change things (and thus checksums), I'd like to
suggest that the CS should not transform the data as it come in. There
is a difference between a meeting which repeats for five days and 5
unique events.  

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Jan 2000 12:35:24 -0800

> implementation or think that it's ok to ask the user to re-enter data.

I think we agree.

	If a CUA deposits a VCALENDAR with the following VEVENT:

			BEGIN:VEVENT
			DESCRIPTION:.....bla bla baa
			SUMMARY: boring....
			.
			.
			END:VEVENT

I say the CS may return:

			BEGIN:VEVENT
			SUMMARY: boring....
			.
			.
			DESCRIPTION:.....bla bla baa
			.
			END:VEVENT

And it is the same. No need to preserve the same data in EXACTLY the same order.
And this by the way would break a signature that may have come in with the
original data. I say - so what - the signature is not an ical object and
the signature is only for accounting - out of scope.

> is a difference between a meeting which repeats for five days and 5

I agree. And I did not like the RRULE transformed into a single VEVENT
with 5 RDATEs. But it is the same thing.

---

From: John Stracke <[email-masked]>
Date: Mon, 17 Jan 2000 11:35:47 -0500

> the signature is only for accounting - out of scope.

The signature is for security, which is never out of scope.  We clearly can't mandate
that the server preserve end-to-end signatures (if we did, nobody could build a
conformant server without throwing away their existing data store); but we ought to
provide a protocol that *can* deliver the signature if the server is built to do it.

(Encryption, of course, is another matter; you can't reasonably build a calendar
server that isn't allowed to know what time your events are, or you'll never be able
to search it efficiently.  :-)

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Your reality, sir, is lies & balderdash, and I|
[email-masked]|am pleased to say I have no grasp on it        |
|                |whatsoever!" --Baron Munchausen                |
\================================================================/

---

From: Willy Mills <[email-masked]>
Date: Thu, 20 Jan 2000 11:07:37 -0800

At 12:35 1/14/00 -0800, you wrote:
>Attachment Converted: "d:\eudora\attach\doug12.vcf"
>

The general solution is:
Signing:
A) Transform the object to a specified canonical form.
B) Sign the transformed object.
C) Associate the signature with the original object.
Validating:
A) Retrieve the object and the associated signature
B) Transform the retrieved object to the specified canonical form.
C) Verify the signature matches the canonical form.

The transformation to canonical form would seem to be highly dependent upon
the application context. It should delete irrelevant data and provide a
deterministic form (specified sort order, etc.) for the remainder. The
notion of what is "irrelevant" is the application context dependent
aspect. So specifying any canonical form would seem out of scope
as it depends on the application use.
An issue I find relevant is the issue regarding RRULE preservation.
Am I correct in my suspicion that converting RRULE data to
canonical form (equivalently comparing two RRULE items for equality)
is one of those algorithmically hard problems? Is it even computable?
If so then transforming RRULE data makes it difficult to solve
the signature problem. The issue of data inclusion and ordering
is not nearly as problematic.

I'm not proposing any changes, just hoping to clarify
some issues.

Greetings,
Willy <[email-masked]>