[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: EPM (was RE: [dss] freezing doc, and next steps)
Trevor, please refer to my responses below, marked as <UPU> Steve -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: Wednesday, June 04, 2003 2:58 AM To: dss@lists.oasis-open.org Subject: Re: [dss] RE: EPM (was RE: [dss] freezing doc, and next steps) Steve, Thanks for the clarifications. A few more questions- At 05:24 PM 6/3/2003 +0200, Gray Steve wrote: >Please refer to my responses to Trevor's questions below, marked with <UPU> > >-----Original Message----- >From: Trevor Perrin [mailto:trevp@trevp.net] >[...] > - If so, and the EPM has to log everything, and compare against this log, >why doesn't it just store the hash, what's the point of using public-key >signatures? > ><UPU> >I assume you are asking this question in the context of the CheckIntegrity. >This context is too narrow and cannot be used to generalize. The >CheckIntegrity operation was introduced to support Web-based form signing >under the scenario where the subscribing application is serving the page to >be signed to the client browser and the verification is going off to the EPM >for verification. The application can subsequently reasssure itself that the >data that it presented for signing was indeed what was actually signed by >calling the EPM with a CheckIntegrity passing in the original data. >Secondly, and more importantly, there exists no legally binding precedence >for the validity of digital hashes, there is for digital signatures. ></UPU> Are you saying that the client browser goes to an EPM to sign the form, and then the web app calls CheckIntegrity to ensure that the client browser signed what was presented? <UPU> No, the EPM is doing verification. CheckIntegrity is used again by the web app as a final check on what it has received back is the same as what was signed and EPM'd. </UPU> > - what kind of CAs and PKI are assumed? > ><UPU> >Technically, there are no assumptions outside of X.509v3 certs. Numerous CRL >and CRL/DP approaches are supported. >A chain of trust is assumed between senders and receivers. In the Postal >deployment scenario, Postal CAs use the same, subordinate, or cross-certify >to a Common Global Trust Model (CP and CPS) maintained by the UPU. ></UPU> It sounds like the EPM protocol could be used in different settings, but there's a particular "Postal Deployment Scenario" which requires a mandated core of EPM functionality, <UPU> Yes, this is correct </UPU> and is going to involve various national-scale CAs cross-certifying with a UPU bridge/root CA. Is this right? <UPU> This may be the case, however, we have not finalised our Global Trust Policy at this stage. Some countries will likely subordinate to a UPU Root, whereas others with existing CA infrastructures as well as others with strict government accreditation policies may not allow subordination to a root/bridge. We are also looking at the scenarios that exist today with notaries in the paper world. There are no equivalent laws/policies (that I am aware of) that relate to cross-accreditation. For example, do we ever verify signatures on paper when we sign NDAs. When notaries are used do would a relying party in one country sue a notary in another country if an international contract (that was notarised) was later proven to be falsely signed. And under which law would you sue the notary. You have 3 options: the governining law of the contract, the law of the relying party's contry or the law of the notary's country. Perhaps we don't need cross-certification with the EPM as a validation service that can present all evidence related to who, what, why, when.</UPU> I assume you'll tell us more about the web-based signing scenario and other usage scenarios in your use case input, so I'll just ask about specifics: <UPU> Yes </UPU> - 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> - 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> - 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 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> - What's an eVerifier? <UPU> This is a reference to a specific product which doesn't belong in the document - to be removed </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> - Is the EPM protocol intended to be used over something like TLS, or WS-Security? <UPU> TLS - eg. SSL Yes, the client to server protocol can be session protected. Elements of WS-S are being incorporated, eg, authentication in future work </UPU> - It seems the "normal" use of EPM assumes a global PKI, and that end-users have their own certs/keypairs. Operations like "Sign" and "Decrypt", which use certs/keypairs stored at the EPM, are optional. How important are these operations to the parties who are designing, and intend to deploy, EPM? Are they expected to be rarely supported and hardly ever used, or to be an important part of the system? Delegated confidentiality service shared <UPU> Yes they are optional. We will provide scenarios under which these optional services are used Not so important because they are optional, eg. Delegated confidentiality services We believe them to be differentiators and high value optional services </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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]