Subject: RE: Last Call: Compressed Data Content Type for S/MIME to Proposed Standard

From: [email-masked] (Peter Gutmann)
Date: Tue, 16 Jan 2001 01:46:43 (NZDT)

"Jim Schaad" <[email-masked]> writes:
 
>I have one minor comment.
>
>To be consistant with all of the other drafts coming out with
>SMimeCapability values, I would like to see the following text added to the
>end of Section 2.
>
>The SMIMECapability SEQUENCE representing the ability to process compressed
>content MUST be DER-encoded as the following hexadecimal string:
>       30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 01 09.
 
Someone else made that comment as well earlier on (or was it you, I can't 
remember?).  I can't imagine why you'd need that, it's a completely redundant 
comment, if you want to know how to DER encode something, see the DER.  By 
that logic every new standard would have to contain dozens (or in the case of 
something like son-of-2459, hundreds) of extra lines of text specifying the 
DER encoding of each element.  
 
Was there some historical reason why this was included originally and then 
everyone copied it without knowing why (I smell a vendor-specific bugfix/hack)?
 
Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Jan 2001 10:36:33 -0800

This is to some degree redunant information.  The reason that I want it
included is simply because it is stated that a binary comparison is used for
SMIME Capability rather than decoding and comparing.  Puting the actual
bytes into the document means there is no possiblity to get this wrong when
doing this binary compare.

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Tuesday, January 16, 2001 1:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call: Compressed Data Content Type for S/MIME to
Proposed Standard

Someone else made that comment as well earlier on (or was it you, I can't
remember?).  I can't imagine why you'd need that, it's a completely
redundant
comment, if you want to know how to DER encode something, see the DER.  By
that logic every new standard would have to contain dozens (or in the case
of
something like son-of-2459, hundreds) of extra lines of text specifying the
DER encoding of each element.

Was there some historical reason why this was included originally and then
everyone copied it without knowing why (I smell a vendor-specific
bugfix/hack)?

Peter.