Phil,
I think the OSS tool may be sufficiently well-developed to check that
the XML example encoding you are producing is indeed consistent with
CXER. It would be good to have this checked. You need to contact
Bancroft.
John L
Phil Griffin wrote:
>
> Busy week in Redondo Beach this week with my suggested
> X9.84 schema revisions being approved. I've posted them
> to a working page on my site, http://asn-1.com/x984.htm
> if you'd like a look.
>
> There is a partially completed XML encoding at the end
> of this file. It gives you some idea where this is going.
> Once I've worked it out and tested it with my code I'll
> incorporate this one and some more simple examples into
> the XCBF document Examples section.
>
> One big change comes in the cryptographic processing. In
> the original version of X9.84, integrity processing was
> performed on a single value of BiometricObject in its
> encoded form. For privacy processing, only the biometric
> data was encrypted and the header was left in the clear
> for ease of handling the object without decrypting the
> payload.
>
> But this left a security hole, since the header was not
> cryptographically bound to the data. This problem has
> been corrected. In the revised X9.84, all cryptographic
> processing is performed on EncodedBiometricObjects. The
> headers in the privacy and privacy with integrity objects
> are now optional. This allows you to leave them in the
> clear for ease of use in secure environments, and to
> remove them for transport or use in environments that
> may not be secure. The headers are cryptographically
> bound to the data, so they can always be recovered.
>
> <IMPORTANT>
> Comments are welcome on any and all of this. And I would
> like you each to review the design carefully. Once you
> have understood the changes, I'd like us to agree that
> this revised version of X9.84 will be adopted by our
> group and that I should change the XCBF document to
> reflect these changes. Note that there is a zip file
> link on the page that you can use to eliminate the
> black screen while you read.
> </IMPORTANT>
>
> One other significant event occurred at the meeting. I was
> convinced and reassured that no special preparation of the
> XML markup was needed for safe encryption. As some of you
> know, this was the bugbear I was worried would delay our
> work and its rapid completion.
>
> Turns out that some algorithms are not secure for use on
> data that contains a known text prefix or a lot of redundancy.
> But no X9 algorithms suffer from these problems. So if I rely
> only on algorithms approved for use in the financial services
> industry and I avoid others, I need only encrypt the XML markup
> the same as I would any other format of data.
>
> Again, as with signatures, we can follow exactly the same
> cryptographic processing requirements in use today for
> compact binary encoding of information using ASN.1 DER
> with our XER encoded biometric data.
>
> Phil
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
