Subject: Re: draft-housley-binarytime-00.txt

From: Peter Sylvester <[email-masked]>
Date: Fri, 17 Sep 2004 13:18:00 +0200 (MEST)

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.
> 
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Sep 2004 11:54:28 -0400

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