RE: [dss] RE: EPM (was RE: [dss] freezing doc, and next steps)

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

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