Subject: [lemonade] server-side cryptographic oeprations

From: Cyrus Daboo <[email-masked]>
Date: Fri, 11 Mar 2005 11:19:52 -0500

Since I have been thinking about this type of operations for a while, I 
though I would pass on my notes on this issue, as they may be useful. Feel 
free to comment on this, including pointing out any flaws...

Notes on server-side cryptographic operations:

NB Assumes that client<->server session is encrypted (TLS). Client has to 
implicitly trust the server to a degree in that unencrypted data may reside 
on the server, if even only on a temporary basis. However, user's private 
key/cert is not stored or passed to the server - it always resides on the 
client.

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

Alternatively the client could ask for the appropriate hash, and then 
catenate the multipart/signed itself to the server, using a reference to 
the original message. However, I would be vary of doing that, as it 
requires the server and client to 'generate' exactly the same data for the 
first part of the multipart/signed. For example, if the message being 
signed is only a single part (e.g. text/plain), in order to generate 
multipart/signed, the MIME headers from the top-level 2822 headers in the 
original message need to be extracted and placed in the first part of the 
multipart/signed so that the hash can be calculated over that. If the 
client and server differ in even the slightest way on how that header 
extraction is done (e.g. slightly different line wrapping) then that would 
break the digital signature. Thus I think it better for the entity 
generating the hash to also be responsible for creating the 
multipart/signed for consistency.

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.

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

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

Obviously the details of what crypto 'packets' get extracted and passed 
around will depend on the type of crypto in use (i.e. PGP or SMIME). It may 
be necessary to define a 'generic framework' for these types of operations, 
and then have separate profiles for PGP and SMIME for practical 
implementations.

-- 
Cyrus Daboo

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

---

From: Pete Resnick <[email-masked]>
Date: Sat, 12 Mar 2005 16:17:06 -0600

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:

>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
>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.

>3. If public key/cert is not found, server asks client to provide 
>one, and fails if one is not returned
>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.

>4. Server builds multipart/encrypted etc and stores in client 
>specified mailbox
>
>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.

>2. Client requests digital signature operation providing message 
>seq/uid, crypto parameters (e.g. PGP or SMIME, hash type etc)
>4. Client processes hash with user private key to provide crypto 
>'signature packet'
>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

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 12 Mar 2005 18:09:14 -0500

Hi Pete,

> 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:

Agreed, signed/encrypted data can appear not only at the 'top-level' of the 
message, but as any part within the message, so clients need to be able to 
communicate a body part specifier to the server.

> 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.
>
> 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.

Bear in mind that there are non-clear-text signature options available and 
those bundle up the data and signature into one part (e.g. 
application/pkcs7-signature).

One of the tasks that the design team ought to do is enumerate all the 
possible message formats that can be used for sending cryptographic data, 
because those will dictate to a certain extent how this protocol will work 
given the facilities in IMAP etc. For example, crypto messages can contain:

multipart/signed
multipart/encrypted
application/pkcs7-signature
application/pkcs7-mime (typically used for S/MIME encryption - 
multipart/encrypted is not used with S/MIME)

Then there is the 'inline' mode of PGP with --- BEGIN PGP --- etc 
delimiters in the text. We should rule out support for that IMHO, as that 
mode is not at all IMAP friendly in that you cannot detect it without 
either searching on the server for the boundary strings, or downloading the 
content and doing local search for the strings. With the other types, they 
can all be detected via IMAP BODYSTRUCTURE.

Also, one thing I left out of my initial list was the combined 'encrypt & 
sign' and 'decrypt & verify' operations. We need to support those as well, 
so should ideally design the separate pairs of operations so that they can 
also work together for the combined crypto action.

> 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?

If you want the client to do the actual hash calculation, then of course it 
has to have local copies of all the parts of the message being signed. 
However, it can still use catenate to reconstruct the message on the server 
without having to upload the parts already on the server. In other words 
you pay half of the cost of data transfer, with the tradeoff that you can 
be absolutely sure of what you are signing. You also have to make sure that 
the client and server generate EXACTLY the same message data byte-for-byte 
in order for the signature to be valid.

In terms of the private key - frankly I won't trust the server with my 
private key - or more specifically I don't trust the server admin. 
Alternatively if you do trust the server with your private key, then this 
whole protocol design becomes somewhat moot as all crypto operations take 
place on the server. The question of where the private key can reside is 
the first that has to be answered...

-- 
Cyrus Daboo

---

From: Pete Resnick <[email-masked]>
Date: Sun, 13 Mar 2005 09:02:38 -0600

On 3/12/05 at 6:09 PM -0500, Cyrus Daboo wrote:

>Bear in mind that there are non-clear-text signature options 
>available and those bundle up the data and signature into one part 
>(e.g. application/pkcs7-signature).
>
>One of the tasks that the design team ought to do is enumerate all 
>the possible message formats that can be used for sending 
>cryptographic data, because those will dictate to a certain extent 
>how this protocol will work given the facilities in IMAP etc.

Yes. Blech. It will have to be a decision based on how much 
deployment of this stuff there is.

>Also, one thing I left out of my initial list was the combined 
>'encrypt & sign' and 'decrypt & verify' operations. We need to 
>support those as well, so should ideally design the separate pairs 
>of operations so that they can also work together for the combined 
>crypto action.

You would not support those by iterative operation?

>>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 
>>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 
>If you want the client to do the actual hash calculation, then of 
>course it has to have local copies of all the parts of the message 
>being signed. However, it can still use catenate to reconstruct the 
>message on the server without having to upload the parts already on 
>the server. In other words you pay half of the cost of data 
>transfer, with the tradeoff that you can be absolutely sure of what 
>you are signing.

True enough, though I think we'd agree that downloading everything is 
not desirable in some cases.

>In terms of the private key - frankly I won't trust the server with 
>my private key - or more specifically I don't trust the server 
>admin. Alternatively if you do trust the server with your private 
>key, then this whole protocol design becomes somewhat moot as all 
>crypto operations take place on the server. The question of where 
>the private key can reside is the first that has to be answered...

I wasn't arguing that the server should have *your* private key; I 
agree that this would make the whole conversation moot. I was arguing 
that the server should have *a* private key if you want it to sign 
things. Then you're not saying that *you* signed the message; you're 
saying that the *server* signed the message. When you have (e.g.) PGP 
sign on a message on your local machine, you are saying, "The 
hardware and software that I have enough trust in to expose my 
private key to has generated this hash for this message." That's a 
very different statement from what you're suggesting.

Maybe we need some security input on this, but it seems to me that 
the exposure in this case is different from the other three.

pr