Re: [xcbf] X9.84 question - Representation of dates/times

[Phil Griffin <phil.griffin@asn-1.com>]

Alessandro Triglia wrote:
> 
> Hi
> 
> I have another question about X9.84.
> 
> When a BiometricObject value is encoded in DER, CANONICAL PER or CANONICAL
> XER, I believe that there should be a unique way to represent in encodings
> the dates/times carried by some of its fields.

With respect to the ASN.1 encoding rules that you cite
above, I'm sure you'll agree that there is one and only 
one way to encode a given value of type BiometricObject. 

There is no notion in ASN.1 of inclusive versus exclusive
canonicalization. Canonical ASN.1 encoding rules are very
simple and easy to work with in that respect.

> However, the relative OID format for dates/times (defined in X9.84 and in
> X9.68) allows to represent the same date/time in multiple ways as an
> abstract value (a relative OID value), and therefore also in canonical
> encodings.

Let me first quibble over your choice of words so
that I am clear in what you're saying. In the sense
of what the X9 standards "allow", you are correct that
there is more than one abstract value that represents
a given date and time.

Given a particular date and time, the user may choose
to represent this value by including or omitting the
trailing zeros, so long as the first three object 
identifier components are present. 

So there are then different abstract values that map
to the same date and time. But for each such abstract
value, there is one and only one way to encode it 
using a canonical encoding rule.

If so, I agree that you are correct. 

> 
> The X9.84 document says:
> 
> **********************************
> "Values of type DateTime can vary in length, making it possible to specify
> the use of default values for some trailing components. When the type
> DateTime defined in this standard is used to specify a time value, it shall
> be represented as a series of at least three and no more than seven integer
> components. Any components containing zero values may be omitted, starting
> with the seventh component backwards through the fourth component until the
> first non-zero value is encountered. For example, January 1st, 2001
> 00:00:00 (GMT) can be specified as { year(2001) month(1) day(1) }."
> **********************************

The problem you cite here lies with the text "may be omitted",
and "can be specified". These could be changed into "shall be
omitted" and "shall be specified", so that there is only one 
way to form an abstract value to represent a given date time in
XCBF. 

> 
> and the X9.68 document also says:
> 
> **********************************
> "This value can be DER encoded in only four octets."
> **********************************

Same issue here.
 
> For example, an endpoint may represent "Feb 25, 2002" as {2002 2 25} and
> another endpoint may represent the same date as {2002 2 25 0 0 0}.  These
> two relative OIDs are two distinct abstract values, but represent the same
> date.  The canonical encodings of these relative OID values would be
> different, even if both represent ultimately the same information (a
> date/time).

Correct. We give the sender flexibility here that is
probably of little value. We could require either that
trailing zeros always be preserved or that they always
be omitted.
 
> The problem is that, unless the application represents the date/time
> *internally* as a relative OID (which is very unnatural), or unless it
> keeps track of the length of the relative OID first-decoded, it is possible
> that a re-encoding of *the same date* will produce a different relative OID
> and hence a different encoding.

The only context that I can see in which this could 
possibly cause a problem would be for signature
verification. And signature verifiers should always
preserve what they receive - but of course they 
sometimes do not.

> In other words, we are in the presence of "sender's options" at the
> protocol level (not at the encoder level) that may defeat the purpose of
> using canonical encoding rules.

Point taken.
 
> So my question, with respect to the scope of the XCBF, is:  Should we
> always produce a relative OID with all 7 components (year, month, day,
> hour, minute, second, UTC designator) and not allow any shorter
> representations where missing OID components default to zeros?  Or should
> we admit that two different encoded messages may be carrying exactly the
> same application semantics?

Personally, I would prefer the later. That is, I would
prefer that we state that these trailing zeros are always
omitted so that the encoded value is always as small as
possible.

The size ranges for biometrics vary widely. I did a
survey in trying to come up with realistic data for use
in X9.84 a few years ago. The range at that time was from
18 bytes to just under two megabytes. 

For the high end of this range, we're not saving anything
worth mention. But for multiple values stored on a smart
card or used in transfer in a bandwidth or battery constrained
environment, it may be beneficial to be as efficient as we
can be.

I would suggest that we adopt text such as 

"Values of type DateTime can vary in length. This makes it 
possible to specify default values for some of the trailing
components. In XCBF, when a value of DateTime is used to 
specify a date and time, it shall be represented as a 
series of at least three and no more than seven integer
components. Any components containing zeros shall be 
omitted, starting with the seventh component backwards 
through the fourth component until the first non-zero 
value is encountered. For example, January 1st, 2001
00:00:00 (GMT) shall be specified as 2001.1.1 ."

But I defer to the editor to come up with better text.

Phil

 
> Alessandro
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>