[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] X9.84 Revision
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC