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

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

This is a difficult discussion.

A simple starting point is to have a digital signature apply to an
encoding (any encoding).  If the encoding is changed, the signature is
invalid.

The second stage is to say that the digital signature applies to the
abstract values, and that it should NOT be invalidated by encoding
changes (a false negative problem).  (This is broadly where we are at
today with DER, CXER, CPER, etc.)

The third stage - which several e-mails recently have touched on (and
yours has really focussed on) is to say that the signature should be
applied to the semantics transferred, so it should not be invalidated
(false negatives) by a change in the abstract syntax carrying the
semantics (in this case additional or missing relative OID components).

It is possible to do the second stage completely (but Hoyt has argued in
the past that it is not needed, and that stage 1 is fine).  Doing stage
3 completely will be much more difficult, but as I seay, recent e-mails
have touched on this.

Note that there is a similar issue on the presence of known clear-text
producing security vulnberabilities for non-disclosure functions.  The
presence of such text at the encoding level is surely something we
(ASN.1) should and can avoid.  The presence of such text at the
application level is really outside our control.

John L


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