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