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

[Alessandro Triglia <sandro@oss.com>]

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.

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.

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) }."
**********************************


and the X9.68 document also says:

**********************************
"This value can be DER encoded in only four octets."
**********************************


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

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.

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.

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?

Alessandro