[xcbf] Outline and scope of XCBF work

[John Larmouth <j.larmouth@salford.ac.uk>]

This thread has got a long way away from where it started - "Re: [xcbf]
X9.84 question - Representation of dates/times".  I have changed the
thread name, but this is a response to Alessandro's latest on the
original thread.

I think that a lot of good points have been made in this discussion, and
we are all a lot clearer on what our base protocol is doing and/or is
not doing that might need addressing in our text.  I guess to make
further progress, we really *do* need the beginnings of a real output
document that we can argue over.  I keep saying I will give some
priority to that, and I will.  But meanwhile (and this is a necessary
precursor to planning any real document), here is my own understanding
of the general scope of our work, ab initio.

These issues may get resolved when I have more fully grasped the base
documents we are working with (there is a lot to read).  But if my
perception of what we are trying to do is widely different from that of
others, then now is the time for people to raise that.  So .....

1.	Biometric data
======================

There are biometric sensors being produced by many different
manufacturers.

They all have different formats for the data they produce (even for the
same sort of data) and standardisation in this area is unlikely in the
near future.

The best we can do (and registration standards are in place) is to
identify the format of any data we carry,  using the registered identity
of the vendor of the equipment and his own identification of the format.

The forms of these identifications are probably going to be Object
Identifiers, or possibly a combination of OID and UUID (???).

We should probably recognise that in the longer term, forms of biometric
data for at least some common sensors WILL be standardised, and
reference to identifications or formats produced by a standards body
instead of manufacturers may be a wise precaution to avoid being
overtaken by later standardisation.

2.	The client-server interaction
=====================================

The underlying industry model is that a client will use one or more
biometric sensors on one or more individuals,  will send the resulting
data to a database server, which will identify records associated with
the individuals providing the biometric data (authentication) and will
return identification of the resources that those individuals are
jointly allowed to tap (authorisation).

Like the biometric data, the authorisation data is also not going to be
standardised in the near future, and may be simply a bank account number
or may be access to some software resource or to some physical area.

Here there is no current registry of organisations defining the form of
authorisation information, I think (although CMIS has some stuff on
this).

We could replicate the registration of biometric sensor manufacturers,
but it may be more sensible to recognise that a sensor manufacturer will
identify BOTH bometric formats for its different sensors AND forms of
authorisation that can be associated with data produced by those sensors
(and used by the client to unlock doors, deliver software, provide
physical money).

3.	Underlying protocols and wrappers
=========================================

The exchanges are expected to be a simple request/response transaction,
but the underlying protocol carrying these (for example ROSE, CORBA,
etc) and any reject messages due to overload, lack of authorisation of
the client to access the server, etc, is beyond the scope of our
standard.

Similarly, the use of wrappers such as SOAP is beyond the scope of our
standard.

The content of the request and response is very much part of our
standard (see below).

5.	The request message
===========================

The request will contain as a minimum:

	a)	identification of the biometric format (manufacturer, and format
within that manufacturer);

	b)	data in that format;

	c)	a time-stamp, and possibly, for audit purposes, identification and
location of the client.  This latter may also be used to authorise
access to the database.  What other authorisation information is needed
for the database access? Is this part of a message wrapper and/or
underlying protocol and out of our scope, or is it within our scope?

	d)	perhaps (to assist in processing in the server) the claimed
identification of the person providing that data;  the form and
identification of such an identification is likely to be determined by
the server, and would again need identification fields.  There are
clearly applications where the claimed identity will be needed by the
server to avoid too heavy processing.  There will be others where the
client (and/or security considerations) make it undesirable or
impossible to provide a claimed identity, so it clearly has to be
optional.

The question of how much of a) to d) needs to be subject to
non-disclosure and signature security algorithms is still to be
determined (????).

What else needs to be in the request?

5.	The response
====================

The response will contain as a minimum:

	a)	confirmation or otherwise of the claimed identity (if one is
claimed), or an identity identification if one is not claimed;  (Again,
for security reasons, only b below, without the identity, may be
returned for some applications.)

	b)	the authorisations associated with the validated identity, or with
the two or more identities that have been validated as part of this
exchange;

	c)	identification of the server and a time-stamp.

Clearly all the above need to be at least digitally signed by the
server.  What parts need non-disclosure (optionally or always) needs
further discussion.

What else needs to be in the response?  Clearly the response has to be
securely associated with the request, probably using some session key
provided in the request.  How much of such work is virgin territory, and
how much is well understood and already standardised?

I think that is enough to be going on with!

John L

Alessandro Triglia wrote:
> 
> At 2002/04/15 19:30 -0400, Phil Griffin wrote:
> 
> >Alessandro Triglia wrote:
> > >
> > > At 2002/04/13 08:50 -0400, Phil Griffin wrote:
> > >
> > > >John Larmouth wrote:
> > > > >
> > > > > Phil,
> > > > >
> > > > > Hoyt's posisition is quite tenable.  Cannonical encodings are not
> > > > > necessary.  If a signature does not validate against the recieved bit
> > > > > pattern, then there is a possibility it has been tampered with, and the
> > > > > message should not be trusted.
> > > >
> > > >Sure.
> > > >
> > > > > Perhaps you could explain why *you* think canonical encodings are
> > > > > useful?
> > > >
> > > >Canonical encodings remove options for the sender, which
> > > >can lead to programs that are more simple to design, and
> > > >easier to understand by people who write, test, document
> > > >and maintain. That's the key benefit in my opinion.
> > >
> > > In X9.84, the data block on which the signature was computed is not always
> > > a physical portion of the message that is transmitted, and when it is a
> > > physical portion of the message it may still be difficult to extract it
> > > from the message.
> >
> >It is certainly true that when confidentiality services
> >are provided, the object that is supposed to remain
> >confidential is not included in the message. Why does
> >this seem to be a surprise to you? This about it. If
> >the confidential information is included in the message
> >in the clear, it can not be confidential.
> 
> Phil, you completely misunderstood me.
> 
> I am saying that, in X9.84, the receiver **has to re-encode** the value on
> which the signature was computed - in order to check the signature - for
> one or more of the following reasons:
> 
>          1) When privacy is used:  the message doesn't carry in the clear
> the "BiometricData" value that is a part of the value on which the
> signature is computed
> 
>          2) With any encoding rules, and in particular with PER, it may be
> difficult to extract a fragment of the encoded message from the entire
> message, without actually decoding the message.
> 
>          3) The encoding rules used to encode the value on which the
> signature is computed may not be the same encoding rules used to encode the
> whole message for transmission.
> 
> As to point 2, notice that in PER, no "BIT WALKER" can find the first bit
> of an encoded value that is a part of an enclosing value, and then the last
> bit of it, without using the ASN.1 type definitions.  The "bit walker" must
> be a PER decoder.  It may throw away the abstract values it has no interest
> in saving, but it is still a PER decoder.  It may use hand-coded program
> code that embodies the knowledge of how to parse those specific ASN.1 type
> definitions, but it is still a PER decoder, although a specialized one.
> 
> Also in XER, a "BYTE WALKER" that is to find the beginning and the end of
> some encoding within an enclosing encoding has to be a XER decoder / XML
> parser. Again, it doesn't need to save the values it finds, but still has
> to know how to parse a piece of XML that is an XER encoding of something.
> 
> As to point 3, that can occur when a "BiometricSyntax" message containing
> integrity information was initially encoded in XER but is later re-encoded
> in PER to be relayed over a slow link.  In this case, the whole message is
> re-encoded in PER, but the signature cannot be re-computed for obvious reasons.
> 
> For one or more of these reasons (that is, either for the sake of
> robustness, simplicity, interoperability, or just out of necessity), it is
> very advisable that:
> 
>          1) The ASN.1 encoding rules used to encode the value on which the
> signature is computed be **canonical**  (C-PER, DER or CXER).
> 
>          2) No deviations from the standard specification of the canonical
> encoding rules (X.690, X.691, X.693) be tolerated.
> 
> Alessandro
> 
> ----------------------------------------------------------------
> 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