Re: [xcbf] X9.84 Revision

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

Actually, this means that both the OID module and the
base biometric module have correct syntax. Note that
I made one change to the OID module, changing all
occurrences of biometric to BiometricInformationSets.

Phil


Phil Griffin wrote:

> Bancroft,
> 
> Appreciate the help. I've been solely focused on the
> design of the X9.84 revision that I've neglected to
> update the schema modules. Best to wait on checking
> the CMS module until I update it to conform with the
> latest X9.73/IETF work.
> 
> But here's the base X9.84 code with supporting stubs
> and OID module that compiles using your ASN.1 schema
> checker with no errors.
> 
> Please verify that my results can be duplicated and
> post your results to this list.
> 
> And please vote on accepting this base module if you
> then find this base module acceptable.
> 
> Phil
> 
> 
> 
> Bancroft Scott wrote:
> 
>> On Tue, 6 Aug 2002, Phil Griffin wrote:
>>
>>
>>>
>>> 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)?
>>>
>>
>> EllipiticCurves ALGORITHM { ... }
>>
>> However, I don't know if that is the only problem.  I recommend that you
>> use a syntax checker to verify its correctness instead of trying to do it
>> by eye.  Even with languages such as C that I have been using for over 
>> two
>> decades I can never be sure that I've caught all syntax errors when I 
>> rely
>> my eyes.  ASN.1 is no different.
>>
>>
>>>>> 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.
>>>
>>
>> I'm trying to help ....
>>
>>
>>>>> 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.
>>>
>>
>>> From the summary of the corrections to X9.84 it is a definite 
>>> improvement
>>
>> on the first version, but I prefer to have a schema that I know is in
>> order before I accept it.
>>
>>
>>>> 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.
>>>
>>
>> No problem.  I was reacting to John's request.
>>
>>
>>>> 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.
>>>
>>
>> Okay.
>>
>>
>>>>> 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.
>>>
>>
>> No, I don't know what they are, or I would not be stumbling around 
>> looking
>> for them.  However, you are referencing these other ASN.1 modules, 
>> what is
>> the URL that points to the ones that you are working with?
>>
>>
>>>>> 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.
>>>
>>
>> See above.
>>
>>
>>>>> 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.
>>>
>>
>> OKAY!  Now I see what I was doing wrong.  I was grabbing the modules that
>> you have on the XCBF site at:
>>
>>     XCBF ASN.1 Schema for XML Markup March 31, 2002
>>     (http://oasis-open.org/committees/xcbf/docs/schema.zip)
>>
>> The modules defined here are outdated.
>>
>> I should have been working with the document, "XCBF XML Common Biometric
>> Format June 13 2002.doc" that you mailed to us in June.
>>
>> I'll take another stab tomorrow using the modules from this document.
>>
>>
>>>> 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.
>>>
>>
>> Yes, I did notice that.  I took it into consideration.
>>
>>
>>> 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.
>>>
>>
>> Yup.  I suspect that most of the problems will disappear once I try using
>> the right set of modules.
>>
>> Do let me know if you prefer for me to hold off on looking at this until
>> you are finished.  I'm more than willing to do what I can to help in 
>> those
>> area where I have expertise.
>>
>> Bancroft
>>
>>
>>
>> ----------------------------------------------------------------
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> 
> X9-84-Biometrics { 
>    iso(1) identified-organization(3) tc68(133) country(16) x9(840) 
>       x9Standards(9) x9-84(84) module(0) biometrics(1) rev(1) } 
>    DEFINITIONS AUTOMATIC TAGS ::= BEGIN
> 
> -- EXPORTS All;
> 
> IMPORTS 
> 
>    -- X9.84 Biometrics Information Management and Security IDs -- 
> 
>    BiometricTypes, CBEFF-Formats, IBIA-Formats, MatchingAIDs,
>    ProcessingAIDs, X9-Formats
>       FROM X9-84-Identifiers {
>          iso(1) identified-organization(3) tc68(133) country(16)
>             x9(840) x9Standards(9) x9-84(84) module(0)
>                ids(3) rev(1) }
> 
>    -- X9.84 Biometrics Information Management and Security CMS --
> 
>    AuthenticatedData, EncryptedData, EnvelopedData, 
>    MACAlgorithmIdentifier, SignatureAlgorithmIdentifier,
>    SignedData
>       FROM X9-84-CMS {
>          iso(1) identified-organization(3) tc68(133) country(16)
>             x9(840) x9Standards(9) x9-84(84) module(0)
>                cms(2) rev(1) } ;
>    
> 
> BiometricSyntaxSets ::= SEQUENCE SIZE(1..MAX) OF BiometricSyntax
> 
> BiometricSyntax ::= CHOICE {  
>    biometricObjects            BiometricObjects, 
>    integrityObjects            IntegrityObjects, 
>    privacyObjects              PrivacyObjects,
>    privacyAndIntegrityObjects  PrivacyAndIntegrityObjects
> }
> 
> BiometricObjects ::= SEQUENCE SIZE(1..MAX) OF BiometricObject
> 
> BiometricObject ::= SEQUENCE {
>    biometricHeader  BiometricHeader,
>    biometricData    BiometricData
> }
> 
> --
> -- All of the cryptographic processing in this standard is performed
> -- on a value of type EncodedBiometricObjects. This is a sequence of
> -- one or more values of type BiometricObject in its encoded form.
>