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: Re: [xcbf] X9.84 Revision


Also, I was hoping to see some comparison data on
encoding like the following example I got from
Bancroft recently.

  BER definite length encoding: 540 bytes
  BER indefinite length encoding: 620 bytes
  DER encoding: 540 bytes
  CER encoding: 620 bytes
  PER Aligned: 58 bytes
  PER Unaligned: 56 bytes
  XER without XCN: 7575 bytes
  CXER without XCN: 5839 bytes
  Your original XML encoding: 5904 bytes

This particular one may not be public as yet,
but there may be similar ones we can use to
show the potential benefits of using other
canonical ASN.1 binary representations of
XML values.

Phil



Phil Griffin wrote:

> I was hoping to prompt Alessandro to submit
> some examples for the document. So far it
> contains almost nothing but ASN.1 schema. It
> lacks XML markup that shows that it is really
> XML work.
> 
> Phil
> 
> 
> John Larmouth wrote:
> 
>> 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>
>>>
>>
> 
> 




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


Powered by eList eXpress LLC