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

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

John,

John Larmouth wrote:
> 
> 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.)

You mean here I think that there is one and 
only one way to encode the abstract values,
so no encoding options are available, and
no changes to the original encoding can
occur.

Note though John that even this does not save
us from poor implementation that leads to 
invalid encodings.
 
> 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).

The proposal here to eliminate sender trailing zero
options has minor benefit. Receivers are still required
to assure that all values are reasonable for use. But to
either require or to recommend that trailing zeros be 
omitted is easy to do in an application and it provides
direction for implementors.

But it wouldn't hurt to say that senders shall omit these
values and receiver shall be prepared to accept them. It
doesn't seem reasonable to reject a record simply because
it happens to include trailing zeros.
 
> 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.

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

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>