Subject: RE: [lemonade] server-side cryptographic oeprations

From: Eric Burger <[email-masked]>
Date: Wed, 23 Mar 2005 11:35:34 -0500

One idea from the PGP list is:

  Let's say we have a message with a large, encrypted attachment.  I don't
trust the server that much, or, for that matter, I know from out-of-band
methods what is in the attachment.  Either way, I don't have a need to
decrypt the message.  Now let's say I want to forward that message securely.
Rather than having to decrypt the message, all I have to do is encrypt the
session key with the public key of the recipient.

Very elegant.

Yet another operation (Forward-without-download without modification using
THIS key).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Pete Resnick
> Sent: Saturday, March 12, 2005 5:17 PM
> To: Cyrus Daboo
> Cc: [email-masked]
> Subject: Re: [lemonade] server-side cryptographic oeprations
> 
> 
> I think this is really good input into the discussion we're starting. 
> I will leave it to the chair as to whether we should rope Cyrus into 
> the design team discussed in Minneapolis.
> 
> Taking these in reverse order:
> 
> On 3/11/05 at 11:19 AM -0500, Cyrus Daboo wrote:
> 
> >Decrypt:
> >
> >1. Client requests server to descrypt a message
> >2. Server extracts 'encrypted to/session key packets' from message 
> >and sends to client
> >3. Client examines server info to determine whether recipient 
> >private key/cert exists, and fails if not
> >4. Client uses appropriate private key/cert to decrypt session key
> >5. Client sends session key to server
> >6. Server decrypts message using session key and stores new message 
> >in client specified mailbox, and optionally sets 
> >keywords/annotations to indicate decrypt details
> 
> The more I think about it, the more I think this is probably right. 
> Since it is not only a message, but perhaps a message part, that the 
> client will want to decrypt, I think step 1 is more likely:
> 
> 1. Client request encrypted session keys from a message or 
> message part.
> 
> I also think that 5 becomes:
> 
> 5. Client requests server to decrypt message (or part) into a 
> specified mailbox given the decrypted session key.
> 
> I can see that being implemented with a modified APPEND command or a 
> variant of CATENATE.
> 
> >Verify:
> >
> >1. Client requests server to verify signature on message, optionally 
> >providing a public key/cert for the verification
> >2. Server will lookup any public key/cert, if not provided
> >3. If public key/cert is not found, server asks client to provide 
> >one, and fails if one is not returned
> >4. Server does verification of message using public key/cert
> >5. Server returns success code to client, along with appropriate 
> >crypto information for client display (e.g. details on the actually 
> >key ids used for signing, date/time of signature etc) and optionally 
> >sets keyword/annotations to indicate signature verification details 
> >on the actual message
> 
> I think overall, this operation is pretty noncontroversial. The only 
> thing I would point out here is that I wouldn't want the server 
> "asking" the client anything. The client can either ask the server to 
> verify without providing keys (which will fail if the server doesn't 
> have or can't get the keys), the client can provide some keys it 
> thinks are right (which will fail if they are the wrong keys), or the 
> client can ask for MIME part with the signature, figure out which 
> public key goes with that signature, and ask the server to verify 
> providing that signature.
> 
> I also think there's another way to approach this one:
> 
> 1. Client asks server for the MIME part with the signature. (Standard 
> IMAP operation.)
> 2. Client asks server for the hash of the plain text message.
> 3. Client verifies the signature against the hash.
> 
> That requires the client to keep track of public keys and is more 
> work for the client, but maybe it's an easy thing to provide.
> 
> >Encryption:
> >
> >1. Client catenates message to the server
> >2. Client instructs server to encrypt message providing a list of 
> >recipients or public keys/certs to encrypt to
> >3. Server will lookup any recipient public keys/certs, if 
> not provided
> >4. Server builds multipart/encrypted etc and stores in client 
> >specified mailbox
> >
> >Alternatively, the encryption could be done as part of the catenate 
> >operation all in one go. The client would need to provide recipient 
> >or public key/cert data as part of the catenate operation.
> 
> Yup. That all seems pretty straightforward.
> 
> >Signatures:
> >
> >1. Client catenates message to the server
> >2. Client requests digital signature operation providing message 
> >seq/uid, crypto parameters (e.g. PGP or SMIME, hash type etc)
> >3. Server returns hash to client
> >4. Client processes hash with user private key to provide crypto 
> >'signature packet'
> >5. Client sends 'signature packet' to server
> >6. Server builds multipart/signed using message and client signature 
> >data and stores in client specified mailbox
> 
> It seems that 5 & 6 seem could be done by the client simply 
> catenating the new signed message to the server.
> 
> But this whole signature operation is the only one of the four that 
> I'm a bit dubious about. There is something different about signing a 
> message for which you've generated the hash and signing a message 
> where the server has generated the hash. In the former, you're 
> claiming that you know that the data was sent in a particular form. 
> In the latter, you're claiming that you know the server said that the 
> data was sent in a particular form. If you never sign your own 
> messages, then there's no difference, but in that case why not give 
> the server your private key for signing purposes?
> 
> pr
> -- 
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade