Peter:
No. That is not what I meant to say. I was trying to answer your query
about the rule regarding 2050 and signing-time.
Five years ago, there was a debate about the signing-time attribute. In
PKCS#9, it only supports UTCTime. There was a debate about using the same
OID with the construct that includes a GeneralizedTime alternative. At
that time, the decision was to align with RFC 2459. X.509 was also being
updated at roughly the same time.
Your question about the experiment is answered in another message.
Russ
At 07:18 AM 9/17/2004, Peter Sylvester wrote:
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.
>
>
>
>