Re: [xcbf] X9.84 Revision

[John Larmouth <j.larmouth@salford.ac.uk>]

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                               j.larmouth@salford.ac.uk
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England				Fax: +44 161 928 8069