[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] X9.84 Revision
So Ed and Bancroft, do you think that the XCBF group should move on to the revised X9.84 ASN.1 as its schema? Phil Bancroft Scott wrote: > On Tue, 6 Aug 2002, 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. >> > > Yes, it compiles cleanly, with the exception of the following two > informatory (not error!) messages: > > OSS ASN.1 Compiler Version 5.4 > Copyright (C) OSS Nokalva, Inc. 1989-2002. All rights reserved. > > "test94.asn", line 603 (X9-84-Identifiers): C0381I: The ObjectSet > 'SHA-Algorithms' is not referenced in a table constraint, and is not > referenced by any Object or ObjectSet, or is referenced by an Object or > ObjectSet which is not referenced in a table constraint. > > "test94.asn", line 659 (X9-84-Identifiers): C0381I: The ObjectSet > 'EllipiticCurves' is not referenced in a table constraint, and is not > referenced by any Object or ObjectSet, or is referenced by an Object or > ObjectSet which is not referenced in a table constraint. > > C0043I: 0 error messages issued, 2 warning or informatory messages issued. > > In the finished module I suspect you will want to reference these objects. > > Also, there are a bunch of problems having to do with the XML value that > you provided in the document. Let me know if you want me to determine > what all the problems are. Some that I have identified so far are: > > 1: > <encryptedContentInfo> > </encryptedData> > > should be: > </encryptedContentInfo> > </encryptedData> > > 2: > <BiometricSyntaxSets> > <BiometricSyntax> > <privacyAndIntegrityObjects> > > should be: > > <BiometricSyntaxSets> > <privacyAndIntegrityObjects> > > 3: > <recordType> 3 </recordType> > > should be: > > <recordType> <id> 3 </id> </recordType> > > 4: > <validityPeriod> 2002.10.3 </validityPeriod> > > should be either: > > <validityPeriod> <notBefore> 2002.10.3 </notBefore> </validityPeriod> > or: > <validityPeriod> <notAfter> 2002.10.3 </notAfter> </validityPeriod> > > And so on .... > > Perhaps it is best to wait until the schema is solid and then we play with > the instance document. Let me know your preference. > > Bancroft > > > >>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> >>> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC