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

From: Peter Sylvester <[email-masked]>
Date: Sun, 5 Sep 2004 19:05:41 +0200 (MEST)

> You read past the part about this being useful for CMS but not for 
> S/MIME.   The situations where saving a few bytes is useful occur when 
> 1) the objects being signed are small, 2) signature values are small 
> (i.e. DSA/ECDSA, not RSA), and 3) encoding overhead is small (i.e. PER, 
> not BER/DER).  There are no existing applications in this space, and 
> thus no backwards compatibilty issues.  But CMS  and a newly defined 
> attribute can be applied to future applications without having any 
> impact on existing apps.

I don't think we are at a point to discuss whether some piece of
additional data creates or does not create in which area. 

- The proposed indication presents information that is already
  being carried in another indication.

- The proposed indication doesn't provide anything new. 

- No argument of a concrete need has been given. 

- All arguments concerning complexity of treatment are extreemly weak
  even without comparing to what has to be done already for CMS SignedData

- If one assumes the availability of a PER coder/decoder and a DER
  signature creation/validation at the same time, then complexity
  is even less an argument. 

- If someone has problems with embedded systems that maybe some
  very simple subset of BER and a much more limited syntax than
  SignedData could be used, why stay with CMS at all? 

- If you want to save data, then code all relevant information inside
  data, and not within attributes. 

- unless there is an existing example for that use, included as
  an example inside the text, I don't think that we are even at
  an experimental state.

- The proposition below about an alternative way does not mean
  at all that I think that the whole concept is useful at all, 
  or in other words, I just made a joke. 

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

I guess you are right with your observation about potential
problems (cf my last point above).

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Sep 2004 16:59:35 -0400

Dear S/MIME WG:

I have just sent an update of my binary time draft to the Internet-Draft 
repository.  It is intended to be published as an experimental RFC.  Thank 
you for the review that I have received thus far.  The document has greatly 
improved from this review.

The document should appear in the Internet-Drafts repository in a day or 
two.  I look forward to a new round of comments.

Russ

---

From: Alfonso De Gregorio <[email-masked]>
Date: Thu, 09 Sep 2004 09:46:57 +0200

At line 125 and 134: s/midnight, January/00:00:00 UTC, January/
or midnight UTC.

alfonso