Re: [xcbf] X9.84 Revision

[Ed Day <eday@obj-sys.com>]

Yes, I think that is a good idea.

Regards,

Ed

----- Original Message -----
From: "Phil Griffin" <phil.griffin@asn-1.com>
To: "Bancroft Scott" <baos@oss.com>
Cc: "xcbf" <xcbf@lists.oasis-open.org>
Sent: Wednesday, August 07, 2002 4:40 PM
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>
> >>>
> >>
> >
> >
> >
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>