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.