OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [xcbf] X9.84 Revision

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

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.

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.

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC