Re: [xcbf] X9.84 Revision

[Phil Griffin <phil.griffin@asn-1.com>]

Bancroft,

I have not finished writing these yet. But the most
current OID module is in the XCBF document in the
private area of the XCBF site. It is almost
certainly complete. The CMS module is in a bit of
flux if you're using sophisticated tools. I've
hand coded this stuff twice before and did again
for my XCBF tools - I find that the encoding is
not too complex and it is the cryptographic
processing and key management that are most
important.

Completion of the CMS module has been awaiting two
events that I thought it best we coordinate with.
One is the latest revision of the IETF SMIME RFC,
and the other is the reballoting version of X9.73.
It is desirable, long term, for these two standards
and XCBF to all use the same identifier and type
names for common types such as SignedData.

SMIME is nearly through their review process. X9.73
was changed to its final version last week in Redondo
Beach. Over the next week or so, I'll try to complete
the revision of our XCBF module and incorporate this
into the XCBF document.

So, are you voting to move ahead with the new X9.84?

I have had no intention of publishing every single
type needed to compile the XCBF ASN.1. The likes of
DomainCertificate and Certificate and such are not
really ours to control. But I'm open to considering
this, perhaps as annex materials. Note that I leave
comments in the IMPORTS statements to tell readers
where to find the appropriate modules.

For your compiler, I would suggest that you test by
stubbing out missing types, using the likes of

    Certificate ::= SEQUENCE {}
    DomainCertificate ::= SEQUENCE {}

Phil


Bancroft Scott wrote:

> Phil,
> 
> Where can I find complete and clean definitions of the various modules
> referenced directly or indirectly by http://asn-1.com/x984.htm?
> 
> On the OASIS XCBF website I can find XCBF-CMS.asn, XCBF-OIDs.asn and
> XCBF-Biometrics.asn, but these are not sufficient to resolve all
> references found in x984.htm.  Indeed, modules such as that found in
> XCBF-CMS.asn are not complete, for they reference the items such as
> id-encryptedData and id-ct-authData, but never define them. You will
> notice that the module names in these files are different from the
> ones that you reference in x984.htm.  Where to find the most current
> version of all these modules so that I can check them as John requests?
> 
> Bancroft
> 
> 
>>---------- Forwarded message ----------
>>Date: Tue, 06 Aug 2002 12:52:02 +0100
>>From: John Larmouth <j.larmouth@salford.ac.uk>
>>To: Phil Griffin <phil.griffin@asn-1.com>
>>Cc: xcbf <xcbf@lists.oasis-open.org>
>>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
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
> 
>