Re: draft-housley-binarytime-00.txt

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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