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

[Ronald v. K. <rv...@ab...>]

Hi,

two remarks... inline

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

I think you should always do both to ensure the certificate that is used 
is not revoked

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

That is why renewing a certificate that has expired should be done while 
keeping the same public/private keypair. You should then be able to 
verify the old signature  with the new certificate. If renewing a 
certificate is the same as getting a completely new one (with new keys) 
it's another story.

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