Re: [xcbf] Question about X9.84

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

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");

This is the intention, though it is not clearly
conveyed in the text. Local time has little value
without context.

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

The Z is present in the example given in X9.84, which 
speaks to the DER case required in X.509 and assumed 
in X9.84 because of its strong ties to IETF SMIME. 

  example DateTime ::= { 
     year(2001) month(1) day(1) 
        hours(0) minutes(0) seconds(0) z(0)
  }

  In the XML Encoding Rules this could be represented as 

  <DateTime> 2001.1.1.0.0.0.0 </DateTime>

A look at the DER encoding given just below this example
will show that "z(0)" in the relative OID representation 
of a GeneralizedTime value indicates that the "Z" (Zulu)
is present. This is what "same time" means in the 
statement:

   The same time expressed in example, when encoded
   for transfer using DER, requires fifteen octets 
   and results in the hexadecimal value "32 30 30 31
   30 31 30 31 30 30 30 30 30 30 5A".

A little nerdy I think, in general. Who but a programmer
would recognize "5A" as the hexadecimal value for Z? We 
should aim for better text in XCBF that can be understood
by any reader. 

Also note that this text appears to have been grabbed 
verbatim from another context, X9.68 - 2001: Digital 
Certificates for Mobile/Wireless and High Transaction
Volume Financial Systems: Part 2: Domain Certificate 
Syntax, and just dropped into X9.84. 

The editor probably meant to modify the text for use in
an X9.84 context later and none of the reviewers noticed
a problem. It likely just fell through the cracks.

Consider the reference to X.509 certificates which has 
scant if any relevance in an X9.84 context, but which has
much relevance in X9.68, which provides an alternative
representation of an X.509 certificate, and therefor seeks
to assert that no representation capability is lost by the
squeezing out of some bits by the use of RELATIVE OID.

I'm guilty of writing this text for use in X9.68. This
US standard is being proposed as a new work item in ISO
TC 68 this month. If it's approved, I'll try to fix this
problem there.

Phil

 
> Alessandro
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>