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

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

Bancroft Scott wrote:
> 
> 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

Actually Bancroft, you're totally wrong here. You're
thinking only about the sorts of rules you commonly
make in the ASN.1 standards. This is an application
standard, and it would be perfectly within scope to
assert that trailing blanks should not be used by a
message sender. The two strings you provide in fact
would fail an exact match test, yet they would appear
when displayed to a human user exactly the same.

> 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

Again, this is not an ASN.1 issue. It is an application
issue. It has nothing to do at all with what a general
purpose tool would do with an XML value of type RELATIVE
OID. Nothing at all.

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

I have already stated that providing such guidance has
marginal benefit. But it is easy enough to do. I have
no problem with the current usage, nor do I mind a
change or greater clarity.

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