Subject: Re: CAP: why do we need GENERATEUID?

From: [email-masked]
Date: Thu, 1 Nov 2001 15:49:13 -0500

Appologies for the tardiness.  Real Work (TM) and email problems w/IMC 
have been conspiring against me recently.

John Stracke wrote:
>>Using GENERATEUID doeesn't mean an additional round-trip for each
>>create, a client can request many UIDs at once and store them
>>locally for that session, or forever.
>>
>Oh, that's a good point.

Well then you will never be able to use it with signed or encrypted data 
in the store unless you gave the store the your private keys so it can 
decrypt/reencrypt or resign the data as you.  Some may not mind that the 
data could become "Signed by Some CS Server/Acme" instead of "Signed by 
Joe User/Acme" but some of do find it to be an issue.  I certainly will never give my server my private keys so that it can do this stuff. 

When I get signed meeting requests they are signed by the requestor, not 
by their server.  Im used to seeing this in both email and C&S and Im not 
the only one.

I can see the bandwidth concern for some current low bandwidth clients but 
I strongly resist the idea of designing a protocol for a very narrow pipe 
that exists now when A) the pipes are constantly growing and B) the 
protocol will take a while to get fully fleshed out and implemented.  I 
fully expect that bandwidth will have increased a good dea by the time CAP 
is being tested at CalConnects; at least enough so that requesting a GUID 
and getting it back is an inexpensive option.

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: Fri, 02 Nov 2001 13:49:16 -0700

1) We need GENERATEUID so the servers can generate unique id's.
   Think of the multitude of email programs that started with
   message id '1' for email message-id which was supposed to be
   unique, for each client? What a mess that is/was. NNTP has
   the same mess - each client starts with '1'.

   Server implementations have a need to make sure the UID's are
   unique - as they will have to deal with the problem if it is
   not done. Clients that act as a single CU do not care.
   Servers that have to deal with multiple CU's that could have everyone
   start with UID '1' will care a lot!

2) The ORGANIZERS CS stores the components, a logical place to
   generate the components UID.

> Well then you will never be able to use it with signed or encrypted data in
> the store unless you gave the store the your private keys so it can
> decrypt/reencrypt or resign the data as you. 

Why?

I give your CUA 'pwejfdsj;fjdslkfjsdlkfjdlfdslfdljds' as a unique ID.
Why can't you encrypt it?

3) Encrypted data 'in the store' is out of scope for CAP. We have
   never said that the CS must be able to CRYPT/DECRYPT personal
   MIME messages. 'Your' CUA under your control can ask you for
   your private key. Then using TLS, talk in a secure way to your
   CS. At no point in time have we proposed that the CS store encrypted
   VCALENDAR components. If you wish to do that, great. But it is
   out of scope for CAP.

-Doug