RE: SigningTime

All,

I've seen no response to my suggestion that TimeStampToken could be an
additional way to specify signing time for a document (which makes me
wonder if that message actually made it to the list).

I'm not necessarily proposing that this get added to the S/MIME
specification yet (since the time stamp work is still in its early
stages), but this does argue in favor of the CHOICE construct, since
additional choices can then be added in the future without much trouble.


--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams(_at_)entrust(_dot_)com
--------------------------------------------


> ----------
> From:  jsp(_at_)jgvandyke(_dot_)com[SMTP:jsp(_at_)jgvandyke(_dot_)com]
> Sent:  Thursday, November 13, 1997 2:11 PM
> To:    dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil; ietf-smime(_at_)imc(_dot_)org
> Subject:       RE: SigningTime
>
> All,
>
> I now agree with Dave and Blake's original argument that the SigningTime
> should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
> Dave's point that it is straightforward for the decoding software to examine
> the Tag field of the SigningTime to determine if the time is encoded as a
> UTCTime or GeneralizedTime.  
>
> In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be copied
> to an IETF-controlled S/MIME-related spec.  When that happens, the
> SigningTime needs to be changed to the following syntax:
>
> CHOICE {
>  utcTime           UTCTime,
>  generalizedTime   GeneralizedTime }
>
> I assume that we want to adopt text similar to PKIX I such as:
>
> When encoding the SigningTime attribute, sending agents MUST encode dates
> through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
> GeneralizedTime.
>
> - John Pawling