[Top] [All Lists]

Re: MSG-00 Signing-Time Attribute

1997-12-03 07:51:35
Russ Housley wrote:

I'll meet you half way.  I am concerned about importing from that
specification since it does not use the 1988 ASN.1.


I think that ignoring current standards work is just a bad idea in
general, whether it's ASN.1, PKCS #7, or June '97 X.509. Too many
disbenefits just to use ANY DEFINED BY. The current ASN.1 standards 
contain corrections to numerous defects that must be assumed to 
still exist in 1988 (
Does using the ASN.1:1988 defects help promote interoperability?

I prefer the following language from the current X.509, that the
authors included with their ASN.1 definition. If all of the ASN.1
types referenced in the ASN.1 definition in X.509x97 are also
defined in X.208:1988 then they can be used by SMIME:88. (Not sure 
if GeneralizedTime is part of 1988 or not. It is in 1990.) 

  "Before a value of Time is used in any comparison operation, e.g. 
  as part of a matching rule in a search, and if the syntax of Time 
  has been chosen as the UTCTime type, the value of the two digit 
  year field shall be rationalized into a four digit year value as 

  - If the 2 digit value is 00 through 49 inclusive, the value 
    shall have 2000 added to it.
  - If the 2 digit value is 50 through 99 inclusive, the value 
    shall have 1900 added to it.

  Note - The use of GeneralizedTime may prevent interworking with 
  implementations unaware of the possibility of choosing either 
  UTCTime or GeneralizedTime. It is the responsibility of those 
  specifying the domains in which certificates defined in this 
  Directory Specification will be used, e.g. profiling groups, as 
  to when the GeneralizedTime may be used. In no case shall UTCTime 
  be used for representing dates beyond 2049."

I see no reason for SMIME to have different rules for handling 
type Time than X.509 specifies. It would seem a burden for 
implementors to have more than one handling mechanism.


At 10:58 AM 12/2/97 PST, Scott Hollenbeck wrote:

The June '97 ITU-T X.509 recommendation includes this definition:

Time ::= CHOICE {
 utcTime          UTCTime,
 generalizedTime  GeneralizedTime }

which is used for the notBefore and notAfter values within the X.509
certificate validity period.  Could you just import this definition
and define SigningTime as follows:

SigningTime ::= Time

We're already importing the Certificate definition, and I think it
makes sense to reuse this Time definition instead of defining a new,
identical type for SigningTime.


-----Original Message-----
From:  Russ Housley [SMTP:housley(_at_)spyrus(_dot_)com]
Sent:  Monday, December 01, 1997 2:59 PM
To:    Scott Hollenbeck
Cc:    ietf-smime(_at_)imc(_dot_)org
Subject:       Re: MSG-00 Signing-Time Attribute

I am in the process of adding PKCS#9 attributes that are needed for secure
e-mail to the CMS document.  In the process, I fixed the syntax.  here is
what I did:

10.3  Signing Time

The signing-time attribute type specifies the time at which the signer
(purportedly) performed the signing process. The signing-time attribute
type is intended for use in signed-data.

The signing-time attribute is identified by the following object identifier:

  id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Signing-time attribute values have ASN.1 type SigningTime:

SigningTime ::= CHOICE {
 utcTime UTCTime,
 generalTime GeneralizedTime }

Dates through the year 2049 must be encoded as UTCTime, and dates in the
year 2050 or later must be encoded as GeneralizedTime.

A signing-time attribute must have a single attribute value.

No requirement is imposed concerning the correctness of the signing time,
and acceptance of a purported signing time is a matter of a recipient's
discretion. It is expected, however, that some signers, such as time-stamp
servers, will be trusted implicitly.


At 05:42 AM 12/1/97 PST, Scott Hollenbeck wrote:
In section 2.5.1 of the S/MIME v3 Message Specification, it states
that "Sending agents MUST encode signing time through the year 2049
as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime".  However, the current PKCS #9 syntax for the
signingTime attribute doesn't support a choice:

SigningTime ::= UTCTime

If an updated definition is available somewhere, where is it?
The document doesn't include a reference for attribute definitions.
If an updated definition hasn't been proposed, how about this:

SigningTime ::= CHOICE {
 utcTime           UTCTime,  -- for years 2049 and earlier
 generalizedTime   GeneralizedTime -- for years 2050 and later -- }

Scott Hollenbeck (mailto: 
Xerox Special Information Systems
Arlington, Virginia, USA

Phillip H. Griffin         Griffin Consulting
asn1(_at_)mindspring(_dot_)com        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA

<Prev in Thread] Current Thread [Next in Thread>