OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[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