[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-05 10:12:54

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