RE: [dss] RE: EPM

[Gray Steve <steve.gray@upu.int>]

Once again see my replies below, Steve Gray

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Friday, June 06, 2003 12:04 AM
To: dss@lists.oasis-open.org
Subject: [dss] RE: EPM


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), 

<UPU> OK, the global service is primarily for global standards, policies,
consistency, etc. so that there is a standard service offering from the
Posts on an international scale. On the technical side, all the relevant
information about the EPM is contained in the EPM package that is then sent
to the relying party. For example, the digital signature used for signing,
and the location for doing a CRL check, the Time Stamping Authority, etc.
This is probably better explained demonstrating a transaction involving
multiple parties across borders and this will be provided in our use case
document  </UPU>


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.

<UPU> I suppose this is like an Access Control List that is hard code at the
beginning. In this scenario, the document would have to be encrypted using
the public keys of the parties in the list.  There was a specific
requirement for this, but it is also something that can be achieved through
basic encryption of a docuemnt  </UPU>


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

<UPU> Once again, let us present some scenarios in our use case document
which might clarify hashing and signing further </UPU>

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

<UPU> OK, I will dicuss with my more technical colleagues to see if they
have any comments </UPU>

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

<UPU>  We are still investigating the various laws, but at this stage the
European laws appear to be the most stringent. In North America, the Posts
are able to classify their electronic services as mail and therefore
traditional mail tampering laws can also apply. With case law, this is all
very well, until you get an actual case to test the law. </UPU>

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

<UPU> No, we can't assume this, but the policies of the Posts will be
determined by the Liability they have to accept, with the main concern being
to ensure a certificate is verified efficiently. There will eventually be
many, many applications and accordingly many validation processes. The Posts
will not always be the CA. Therefore, control over how Directories are
configured will not always belong to the Posts. </UPU> 

Trevor 


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php