RE: EPM

[Trevor Perrin <trevp@trevp.net>]

At 06:37 PM 6/5/2003 +0200, Gray Steve wrote:
>Trevor wrote:
>   - The sender's EPM stores certain data about the signed document, indexed
>by TransactionKey, so that when the recipient comes to this EPM and
>requests to Verify the message, the sender could be notified, or the
>request will at least be logged.  But if the recipient goes to his own EPM
>service to Verify, and not the sender's, then how is notification and
>non-repudation of receipt accomplished?
>
><UPU> The services will be linked as part of a global service, however, the
>verify is simply checking a CRL, so that is based on the reference in the
>certificate.
></UPU>
>
>   - How is the ParticipatingParty list used in different use cases?  Its
>function isn't clear to me.
>
><UPU> This relates to closing the group for a particular document, only the
>parties on the list can verify sign, etc. The list is created up front.
></UPU>

It's not totally clear to me what it means that "The services will be 
linked as part of a global service", and whether/how notification and 
non-repudiation of receipt would work on a global scale (when the sender 
and receiver are talking to different EPMs), or what the purpose of 
"closing the group" for a particular document is, but I assume these will 
be elaborated in the use case submission.


>Trevor wrote:
>   - For the "Verify" operation, the client sends a "pkcs7data".  Is this
>just a pkcs7 signature encapsulating the signed data?  Yes. Does that mean
>detached signatures aren't supported?  No.
>Have you considered client-side
>hashing as an option? (the client sends a hash of the content instead of
>the content itself).  This could be supported for both Sign and Verify, and
>gives advantages in efficiency and privacy.
>
><UPU> we support both attached and detached. It is a client application
>decision.  </UPU>

So if the client sends a detached signature as pkcs7data for a Verify 
operation, the server will verify the signature over the signed attributes 
(including the message-digest signed attribute), but the client will have 
to do client-side hashing to check that the document matches this attribute?

If I understand correctly, this requires client-side hashing for detached 
signatures, and disallows it for "attached" signatures.  It might be nice 
if client-side hashing was an option unrelated to the type of signature you 
were verifying.  Also, it would be nice if you could do client-side hashing 
when using an EPM to create signatures (with the "Sign" operation).

These are features that the DSS TC seems willing to work on.  They could 
possibly be a benefit to EPM, if we could fuse our work together.


>   - For the "Encrypt" and "Decrypt" operations, have you similarly
>considered client-side symmetric encryption (the client sends only the
>symmetric key for enveloping when encrypting, and sends only the envelope
>for decrypting; same advantages as client-side hashing).
>
><UPU> we could do non PKI, but we don't right now. We are concentrating on
>DSS for legally binding cases

By client-side symmetric encryption, I didn't mean to change the PKI nature 
of encryption/decryption - but even when using PKI, there's a symmetric 
encryption component using a "Content-Encryption Key", and then there's 
enveloping/de-enveloping of the CEK using asymmetric keys.  EPM has 
"Encrypt" and "Decrypt" operations that do both content-encryption and 
CEK-enveloping at the server-side.

It would be possible to do content-encryption/decryption on the 
client-side.  The client encrypts the content with a symmetric key, then 
sends the key to the server.  The server envelopes it to the recipient and 
returns a CMS RecipientInfo, which the client incorporates into a CMS 
EnvelopedData.  On the receiving side, the client could send the 
RecipientInfo to the server and receive back the CEK.

This has the same advantages as client-side hashing: if the message is 
large (say multi-megabyte), it doesn't have to be sent back and forth 
between clients and servers.  Also, the EPM servers are never given the 
plaintext of the message, so there's greater privacy (the EPM servers 
could, of course, intercept the ciphertext and decrypt it, but that's more 
work).

I'm not sure what legal ramifications there are to this.  Since EPM already 
has Encrypt/Decrypt operations, and client-side en/decryption would only 
reduce the amount of trust that needs to be placed in EPM servers, I 
wouldn't think any?


>Are you concerned with the fact that your protocol may not address legal
>issues if the client has to authenticate at the Server and not with their
>own keys
></UPU>
   - If the Sign operation occurs using the Postal Admin's private signing
>key, then does the recipient of the document receive any information on the
>identity of the client who requested the signature be performed?  If not,
>what good is the signature?  If so, how is this information transmitted
>(for DSS, we're thinking that the client requesting the signature must
>authenticate to the server, and the server inserts the client's name into
>the signature as a signed attribute).
>
><UPU> No, if I understand you correctly, this is totally non-binding legally
></UPU>

This is worth investigating - i.e., what are the legal ramifications of a 
DSS server signing with its own keypair, but embedding the name of a client 
and claiming the signature came from this client?

Certain uses of DSS may not care about legal issues (e.g., where you're 
signing and verifying documents solely for the purpose of sender 
authentication, not for non-repudiation).  In other cases, the DSS may be 
the signer in a legal sense, so the embedded Requestor Identity will be 
purely informative.

However, the most interesting question is whether such a signature could 
stand up in court as having come from the client.  What I know about 
digital signature laws mostly comes from part of Peter Gutmann's crypto 
tutorial -
http://www.cryptoapps.com/~peter/part2a.pdf

He divides these laws into "prescriptive" and "hands-off" approaches.  The 
prescriptive ones (Utah, German, Italian, ETSI, Swedish) have all sorts of 
requirements on exactly what you and your CA must do to comply.  The 
hands-off ones (California, Massachusetts, US E-Sign, UNCITRAL) are more of 
the form "You can't refuse a signature just because it's digital", and 
don't mandate specific technologies (e.g. I signed my (US) tax returns 
using a PIN).  He mentions the EU Directive as a "mixed" approach.

Anyways, I would expect Identified Requestor signatures to comply with 
hands-off laws but not prescriptive ones.  As for the EU Directive, an 
Identified-Requestor signature might be an "Electronic Signature" but not 
an "Advanced Electronic Signature", since it is not "created using means 
that that signatory can maintain under his sole control".

Would you agree with this?  What laws has the EPM project identified as 
most relevant?

>   - The Locate and Encrypt operations let you specify the recipient with a
>DN or URL.  Why not an email address? (or can you include the email address
>as an URL?)  I'm surprised the docs you sent us don't mention EPM in the
>context of secure email, but instead talk about document applications like
>Office, Acrobat, etc...
>
><UPU> Certainly the EPM can be used for email. We can provide more
>information in our Use Case document. For looking up public keys, the LDAP
>protocol doesn't support just an email address </UPU>

You can search an LDAP based on an emailAddress.  But I guess knowing which 
directory to search and how to form the query depends on the directory 
structure.  Probably that's why XKMS and HTTP certstore present a simpler 
interface for retrieving certs and public keys by just querying on the 
email address.

Is EPM assuming everyone will be known by Distinguished Names that are part 
of a properly formed tree, and that there will be a space of LDAP 
directories linked with referrals where you can find people's certificates?

Trevor