Phil:
I understand your concern, but I do not plan to change the OID.
PKIX Part 1 changed the notBefore and notAfter syntax in exactly the same
way. And, the version number was not changed. In fact, I think that
X.509is picking up the PKIX syntax.
Implementations have 52 years to be ready for the new syntax. I do not
think that will cause an interoperabilty problem. [Or, if it does, we will
all be retired.]
Russ
At 04:38 PM 11/13/97 -0500, Phillip H. Griffin wrote:
Since the proposed choice type SigningTime will be a different
type that that defined by RSA in PKCS #9, will there be a new
S/MIME OID assigned to this type?
John Pawling wrote:
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
At 12:51 PM 11/13/97 -0500, David P. Kemp wrote:
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
Constructing the ChoiceOfTime is the easy part. My point is that
it adds
complexity to the SignedData decoding software that must determine
which
choice was chosen. For example, in 2051, our code will need to be
able to
decode stored SignedData objects some of which include SigningTime
with
UTCTime choice and others that include SigningTime with
GeneralizedTime
choice. Sure, there are ways of determining which choice was
chosen, but
the OID check for the signingTime or NewSigningTime attributes
would be
quicker and easier.
I understand. Point taken.
In the signingTime or NewSigningTime attributes environment, you
could use
an equivalent strategy to ensure backwards compatibility by
including the
signingTime (UTCTime) attribute in SignedData objects generated
thru the
year 2049 and including newSigningTime (GeneralizedTime) in SignedData
objects generated on 2050 or after. Using this strategy, in 2051,
the
software can easily determine which flavor of signing time was
included
in a
SignedData object simply by examining the attribute OID.
Yup -- I agree with this. This does sound better.
I agree with the goal of reducing complexity, but I believe having two
different OIDs is more complex than having only a single OID.
There are (at least) three ways of determining the encoding of the
SigningTime field: examining the attribute OID (SigningTime or
NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
or examining the time string itself. For the 2051 example where either
choice may be present, it's easiest to examine the one byte tag type,
rather than to match against two different attribute OIDs or parse
the time string.
If Blake & John are now agreed that two attributes are better than one,
I'm not against it. But IMHO adding a NewSigningTime attribute both:
* makes the spec uglier (having two different attributes to accomplish
the identical functionality, just using different syntax), and
* makes the resulting software more complex.
Phil
--
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
------------------------------------------------------------