Re: [xcbf] X9.84 Revision

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

Bancroft Scott wrote:

> On Tue, 6 Aug 2002, Phil Griffin wrote:
> 
> 
>>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.
>>
> 
> No, it has at least one syntax error (missing ::=). It would be good if
> the modules were syntax checked using tools such as the free syntax
> checker from OSS or France Telecom.
> 


At which line number(s)?


>>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.
>>
> 
> It is good that it can be hand-coded, but it would be great if the syntax
> were clean enough so that it can be verified by machine.
> 


Well it certainly must be before it is finished.
But you know, in all fairness, I AM working on
this without much if any assistance.


>>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 leave that to Alessandro to make that decision for OSS.


Technically, my understanding is that each TC member
has one vote, and "company" has no meaning. Not sure
that I really believe this, but that is what I've
been lead to believe are the rules.


> However, the ASN.1 spec that you have provided needs more work. I have
> been struggling to get it to cleanly compile, cutting here, pasting there.
> A real hassle.  I've given up until we have something more solid.


Then you'll just have to be patient and wait for
me to complete the work.


> BTW, the XER encoding that you have at the bottom of x984.htm is invalid.
> If you cut the encoding and paste it to a file named, say, x984.xml, then
> use a basic XML syntax checker such as Internet Explorer to open the file
> you will see that it contains syntax errors.


You will recall that I stated clearly that it
was WIP and had not been checked using my
product.


> 
>>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.
>>
> 
> I am not suggesting that you publish these.  However, if you reference the
> types then it would help much if you were to precisely identify where the
> types are defined so as to minimize the effort that everyone has to make
> to try and get a complete set of definitions.  A set of URLs pointing to
> the resources that define all directly and indirectly imported types would
> be great.


If you know of such URLs please advise and I will
be happy to include them. X.509 is likely available
on Olivier's site. But I doubt that you will find
the others.


> 
>>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.
>>
> 
> I saw those.  They are no doubt very meaningful to you, but for me
> they just tell me what to enter in google to start my hunt.  URLs
> of some sort would be much better.
> 


Please then DO suggest URLs or alternate text. Any
and all help much appreciated.

>>For your compiler, I would suggest that you test by
>>stubbing out missing types, using the likes of
>>
>>    Certificate ::= SEQUENCE {}
>>    DomainCertificate ::= SEQUENCE {}
>>
> 
> If only it were that simple.
> 
> Where is CBEFF-Formats defined?  I see that it is an information object
> set of class "BIOMETRIC", but this class is locally defined.  Does the
> module that defines CBEFF-Formats (i.e., X9-84-Identifiers) import
> BIOMETRIC from this module (X9-84-Biometrics), or does it redefine this
> class?


CBEFF-Formats  is defined in the XCBF document at
lines 475 and 607. Once in the text and again in
the schema module.

 
> It is hard to tell if x984.htm is syntactically correct without a
> complete ASN.1 schema.


Hah! If you look at it closely you will see that it
contains placeholde text where actual values should
be present. And as I said, it is not complete.

My recollection was that Alessandro agreed to provide
encoded examples. I am working these out on my website
for the purpose of providing general information. I
will of course try to integrate this effort into the
XCBF if examples are not forthcoming from other sources.

Hope that helps.

Phil


> Bancroft
> 
> 
> 
> 
>>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>
>>>>
>>>
>>
>>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>