Re: [xcbf] X9.84 Revision

[Bancroft Scott <baos@oss.com>]

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.

> 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.

> 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.

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.

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.

> 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.

> 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.

> 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?

It is hard to tell if x984.htm is syntactically correct without a
complete ASN.1 schema.

Bancroft



> Phil
>
>
> Bancroft Scott wrote:
>
> > Phil,
> >
> > Where can I find complete and clean definitions of the various modules
> > referenced directly or indirectly by http://asn-1.com/x984.htm?
> >
> > On the OASIS XCBF website I can find XCBF-CMS.asn, XCBF-OIDs.asn and
> > XCBF-Biometrics.asn, but these are not sufficient to resolve all
> > references found in x984.htm.  Indeed, modules such as that found in
> > XCBF-CMS.asn are not complete, for they reference the items such as
> > id-encryptedData and id-ct-authData, but never define them. You will
> > notice that the module names in these files are different from the
> > ones that you reference in x984.htm.  Where to find the most current
> > version of all these modules so that I can check them as John requests?
> >
> > Bancroft
> >
> >
> >>---------- Forwarded message ----------
> >>Date: Tue, 06 Aug 2002 12:52:02 +0100
> >>From: John Larmouth <j.larmouth@salford.ac.uk>
> >>To: Phil Griffin <phil.griffin@asn-1.com>
> >>Cc: xcbf <xcbf@lists.oasis-open.org>
> >>Subject: Re: [xcbf] X9.84 Revision
> >>
> >>Phil,
> >>
> >>I think the OSS tool may be sufficiently well-developed to check that
> >>the XML example encoding you are producing is indeed consistent with
> >>CXER.  It would be good to have this checked.  You need to contact
> >>Bancroft.
> >>
> >>John L
> >>
> >>Phil Griffin wrote:
> >>
> >>>Busy week in Redondo Beach this week with my suggested
> >>>X9.84 schema revisions being approved. I've posted them
> >>>to a working page on my site, http://asn-1.com/x984.htm
> >>>if you'd like a look.
> >>>
> >>>There is a partially completed XML encoding at the end
> >>>of this file. It gives you some idea where this is going.
> >>>Once I've worked it out and tested it with my code I'll
> >>>incorporate this one and some more simple examples into
> >>>the XCBF document Examples section.
> >>>
> >>>One big change comes in the cryptographic processing. In
> >>>the original version of X9.84, integrity processing was
> >>>performed on a single value of BiometricObject in its
> >>>encoded form. For privacy processing, only the biometric
> >>>data was encrypted and the header was left in the clear
> >>>for ease of handling the object without decrypting the
> >>>payload.
> >>>
> >>>But this left a security hole, since the header was not
> >>>cryptographically bound to the data. This problem has
> >>>been corrected. In the revised X9.84, all cryptographic
> >>>processing is performed on EncodedBiometricObjects. The
> >>>headers in the privacy and privacy with integrity objects
> >>>are now optional. This allows you to leave them in the
> >>>clear for ease of use in secure environments, and to
> >>>remove them for transport or use in environments that
> >>>may not be secure. The headers are cryptographically
> >>>bound to the data, so they can always be recovered.
> >>>
> >>><IMPORTANT>
> >>>Comments are welcome on any and all of this. And I would
> >>>like you each to review the design carefully. Once you
> >>>have understood the changes, I'd like us to agree that
> >>>this revised version of X9.84 will be adopted by our
> >>>group and that I should change the XCBF document to
> >>>reflect these changes. Note that there is a zip file
> >>>link on the page that you can use to eliminate the
> >>>black screen while you read.
> >>></IMPORTANT>
> >>>
> >>>One other significant event occurred at the meeting. I was
> >>>convinced and reassured that no special preparation of the
> >>>XML markup was needed for safe encryption. As some of you
> >>>know, this was the bugbear I was worried would delay our
> >>>work and its rapid completion.
> >>>
> >>>Turns out that some algorithms are not secure for use on
> >>>data that contains a known text prefix or a lot of redundancy.
> >>>But no X9 algorithms suffer from these problems. So if I rely
> >>>only on algorithms approved for use in the financial services
> >>>industry and I avoid others, I need only encrypt the XML markup
> >>>the same as I would any other format of data.
> >>>
> >>>Again, as with signatures, we can follow exactly the same
> >>>cryptographic processing requirements in use today for
> >>>compact binary encoding of information using ASN.1 DER
> >>>with our XER encoded biometric data.
> >>>
> >>>Phil
> >>>
> >>>----------------------------------------------------------------
> >>>To subscribe or unsubscribe from this elist use the subscription
> >>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>
> >>--
> >>   Prof John Larmouth
> >>   Larmouth T&PDS Ltd
> >>   (Training and Protocol Development Services)
> >>   1 Blueberry Road
> >>   Bowdon                               j.larmouth@salford.ac.uk
> >>   Cheshire WA14 3LS                    Tel: +44 161 928 1605
> >>   England				Fax: +44 161 928 8069
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
>
>
>