[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xcbf] X9.84 question - Representation of dates/times
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC