Re: draft-housley-binarytime-00.txt

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

Without having looked into whatever archive, by reading the following
two comments, I tend to interprete them as:

  Five years ago there was a debate about whether or not to add a binary time
  format in a signingTime attribute. This had not been adopted, and
  since then, no proposition or urgent need had occured. 

  Since then there has been a revison of the underlying text, i.e., PKCS9,
  so far, I haven' seen any proposals in this direction either
  (I don't have my eyes everywhere, though). 

  Where is the experiment?

> 
> Peter:
> 
> > > >There is no need at all to introduce these options, they serve
> > > >nothing at all, since the other attribute exists.
> > >
> > > We have already had this debate.
> >
> >When did we debate to introduce UTCtime and generalizedtime into the new
> >attribute? I must have missed that? As far as I remember the only
> >debate was whether we need at all a specifiction with seconds.
> 
> I do not recall exactly, but it was prior to the publication for RFC 2630, 
> so it was at least five years ago.
> 
> Russ
> 
> 
> The updated S/MIME MSG spec was just published.  I do not see the WG 
> opening it up for this ...
> 
> Russ
> 
> 
> >Right, that's why we have david Kemp's comment
> >
> >
> >   > The other Peter's suggestion:
> >
> >     Time ::= CHOICE {
> >         utcTime          UTCTime,
> >         generalizedTime  GeneralizedTime,
> >         epochSeconds     INTEGER}
> >
> >   > is fine with me, but I'm not sure existing applications would deal with
> >   > an unrecognized CHOICE value as gracefully as they would with an
> >   > unrecognized attribute.  To avoid problems, the S/MIME -msg spec would
> >   > have to state that epochSeconds MUST NOT be used by sending applications.
> 
> 
> 
>