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