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


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