Re: [ebxmlms-develop] Enhancement request - determining message signer

[Bob K. <py...@ce...>]

Dear Peter,
In fact I have just changed the code on Hermes regarding the 
verification behaviour on EbxmlMessage last week:

1) If the user try the message with non-Null CertResolver, Hermes will 
probably consider the EbxmlMessage must able be verified by 
CertResolver. Therefore, if there is any error on verification using the 
certificates on CertResolver (e.g. the certificates returned by the 
CertResolver is null), it will throw Exception.

2) If the CertResolver is null, the trust store and message's key info 
is the last line on verification signature. If there is error on verify 
the signature using certificate on KeyInfo or the certificate path, it 
will throw Exception.

3) It will be hard to decide the behaviour if both CertResolver and 
Trust store is set, since there may be case that the cert cannot be 
gotten from the key info of the message. The current implementation is 
that the CertResolver is used to verify the signature, and then the 
trust store is used to verify the cert path of the certificate from the 
CertResolver. It may not be the best behaviour, and you can suggest the 
logic it should be.

The EbxmlMessage.isAuthenic() may be okay for the server side 
programming, but it may be quite strange for the packaging in client 
side. In fact I cannot see the difference between isAuthenic() and verify().

Regards,
Bob Koon

Mayne, Peter wrote:

> These are just off the top of my head, but we have to start somewhere. 
> I've catered for my narrow needs. :-)
>  
> 1) Signature
>  
> We need to ensure that a message has been signed by the right entity. 
> (Enforcing the use of CertResolver in the MSH to catch tricky messages 
> might avoid this, but it is still good to see the information.)
>  
> There should be something like a getSigner() method on EbxmlMessage 
> that provides easy access to the <ds:KeyInfo> contents 
> (http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo). This may return a 
> separate class instance which provides KeyInfo access methods.
>  
> There seem to be two different paths, depending on whether the 
> <ds:KeyInfo> has been included in the message header or not. If it 
> has, then it should be sufficient to just return the data. Someone can 
> then look at it and decide if the data is correct.
>  
> If there is no <ds:KeyInfo> data, then there would have to be a 
> fallback to CertResolver on the client side. It should be sufficient 
> to return the certificate that CertResolver returns, which can then be 
> looked at by a person.
>  
> 2) Verification
>  
> We need to ensure at any stage that a message is valid, especially six 
> months after the message has been delivered and the client tries to 
> repudiate it.
>  
> There should be something like an isAuthentic() method on EbxmlMessage 
> that verifies that the message is correcty signed. There should 
> possibly be a parameter that allows the signature to be determined as 
> above (look for <KeyInfo>, fall back to CertResolver), or explicitly 
> force the use of CertResolver only, so the decision about which 
> certificate to use is made based on our CertResolver, rather than 
> relying on a certificate in the message. (Or even do both, comparing 
> the certificate in the message with the certificate from CertResolver 
> to make sure the other end isn't playing tricks.)
>  
> The isAuthentic() method could be boolean. Alternatively, it could 
> throw an exception depending on what is wrong with the message 
> (digests don't match, unexpected certificate, etc). The exception 
> would be useful to try and track why the message isn't authentic.
>  
> (Checking last year's messages with certificates that have since 
> expired might be tricky, but I suspect it's up to CertResolver to find 
> the right certificate. :-)
>  
> I'm not attached to the method names, so feel free to think of 
> something better.
>  
> PJDM
> --
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
> The information contained in this email and any attachments to it:
>
> (a) may be confidential and if you are not the intended recipient, any 
> interference with,
> use, disclosure or copying of this material is unauthorised and 
> prohibited; and
>
> (b) may contain personal information of the recipient and/or the 
> sender as defined
> under the Privacy Act 1988 (Cth). Consent is hereby given by the 
> recipient(s) to
> collect, hold and use such information and any personal information 
> contained in a
> response to this email, for any reasonable purpose in the ordinary 
> course of
> Spherion's
> business, including forwarding this email internally or disclosing it 
> to a third party. All
> personal information collected by Spherion will be handled in 
> accordance with
> Spherion's Privacy Policy. If you have received this email in error, 
> please notify the
> sender and delete it.
>
> (c) you agree not to employ or arrange employment for any candidate(s) 
> supplied in
> this email and any attachments without first entering into a 
> contractual agreement with
> Spherion. You further agree not to divulge any information contained 
> in this document
> to any person(s) or entities without the express permission of Spherion.
>