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.
Russ
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 (http://www.furniss.co.uk/maint/maintop.htm).
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
follows:
- 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.
Phil
At 10:58 AM 12/2/97 PST, Scott Hollenbeck wrote:
Russ,
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.
Scott
-----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.
Russ
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:
hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com)
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
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------