Re: [xcbf] Question about X9.84

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

Bancroft Scott wrote:
> 
> On Thu, 11 Apr 2002, Alessandro Triglia wrote:
> 
> > Phil,
> >
> > I have a question about X9.84.
> >
> > In X9.84, relative OID fields are used to carry dates/times.
> >
> > However, it is not clear to me how the "z" component (the seventh
> > component) of the relative OID is to be used.
> >
> > This component corresponds to the "zone designator" of GeneralizedTime,
> > which indicates:
> >
> >    a) that the time value is a UTC time (when the zone designator is set to
> > "Z");
> >
> >    b) that the time value is a local time, with no indication of how local
> > time relates to UTC (when the zone designator is absent);
> >
> >    c) that the time value is a local time, with an indication of the
> > difference between local time and UTC (when the zone designator is set to
> > hours, or hours + minutes).
> >
> > Can you please clarify how this component is to be used?  What is the
> > implication of its absence, what information does it carry when present,
> > and how is this information represented?
> 
> Consider the following:
> 
>    example DateTime ::= {
>       year(2001) month(1) day(1) hours(0) minutes(0) seconds(0) z(0)
>    }
> 
> I see no canonical/non-canonical issue here as far as the encoding rules
> go.  There are strict rules on how values should be encoded for
> RELATIVE-OID.  If someone omitted the z or seconds or whatever, there is
> no way for a tool to catch it.  Seems to me that this issue has to be
> resolved strictly at the application level - if it is an issue.
> 
> Phil, are there any sender's option as far as DateTime goes?  If no,
> I don't see any problems here, in that once someone does an encoding
> of the value the recipient can get a different encoding (if they were
> to re-encode the value) only if they changed the DateTime value.
> 
> Hmmm ... is there a relationship to DER?  Is there some sort of conversion
> of this time format to/from GeneralizedTime?

Yes. In the context it was written to be used in 
initially, X9.68 Domain Certificates, the intention
was that this notation provided a compact way of
expressing a value of type GeneralizedTime that
was intended to be represented in a DER canonical
encoding.

The text was cut and pasted into X9.84 and never
further clarified. At a minimum, we should provide
text that gives application implementors a few
clues. In X9.84, compactness was still an issue,
but not nearly as important as in X9.68, where 
our goal was to get the content of five X.509
certificates into one K.

There is no canonicalization problem in terms of 
encoding values using CXER. But there are issues
of users being able to represent the same date
and time with more than one abstract value, say
2001.1.1 and 2001.1.1.0 and 2001.1.1.0.0 and
so on.

Not a big deal really. But unnecessary and
without any user benefit.

Phil
> -------------------------------------------------------------------------
> Bancroft Scott                               Toll Free    :1-888-OSS-ASN1
> OSS Nokalva                                  International:1-732-302-0750
> baos@oss.com                                 Tech Support :1-732-302-9669 x-1
> 1-732-302-9669 x-200                         Fax          :1-732-302-0023
> http://www.oss.com
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>