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

[Bancroft Scott <baos@oss.com>]

On Fri, 12 Apr 2002, Phil Griffin wrote:

> As I stated in this thread, if the receiver preserves the
> encoding used in the signature process as sent, it does
> not even matter if the encoding is not canonical or that
> it is encoded correctly.
>
> But an LDAP thread recently reveals that the receiver often
> does not preserve the original encoding of DER objects, which
> can mask encoding errors that become apparent only when
> the receiver tries to encode again and the signature
> check fails.

I think that this is a bit different, Phil.  Given that RELAIVE-OID
is in use, any change to it between decoding and re-encoding would
be fundamental.  It would be exactly as if we had the likes of
"name   UTF8String,".  Although "Bancroft Scott" and "Bancroft Scott   "
are the same abstract values in a sense, we don't make rules for
applications to follow about what to do about trailing blanks.  Along
that line, we don't think of the possibility of trailing blanks as
a sender's option (though it is, in a sense), and we do think of any
decode/re-encode operation that adds or removes trailing blanks as
as a broken implementation.  In summary, I think that unless there are
transformations to/from GeneralizedTime, there is no need to specify
what should be done about trailing zeros in RELATIVE-OID.  Indeed,
specifying that the trailing zeros should be present or stripped for
RELATIVE-OID is a bad idea, IMHO, for we would be imposing rules which,
if broken, makes no difference, other than that a rule is being broken.
That is, such a rule, I think, would serve no useful purpose.

> > 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.
>
> In terms of encoding, perhaps. But this specification is
> about an application, not a tool. So options may be viewed
> differently. As it happens, the text under discussion comes
> from X9.68, produced by the X9F1 Cryptographic Tools WG. The
> use there of "may" rather than "shall" is purposeful, as it
> leaves options open to a given protocol or application.
>
> We get to try to nail down as precisely as possible what
> will be rejected and what should pass.

After thinking this through, my take is that no change should be made
regarding may/shall in the text on the date-time field.

Bancroft

> Phil
>
> > 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
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>