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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Peter
Gutmann
Sent: Tuesday, January 16, 2001 1:47 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: iesg(_at_)ietf(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Last Call: Compressed Data Content Type for S/MIME to
Proposed Standard
"Jim Schaad" <jimsch5(_at_)home(_dot_)com> 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.