[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] X9.84 Revision
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC