From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
At 04:48 PM 2/2/98 -0500, John Pawling wrote:
\xA0
3) Sec 2.6.2.4.\xA0 Please change "MUST use RC2/40" to "SHOULD use RC2/40".
Actually, section 2.6.2.4 should simply be removed. You can't guarantee no
failed decryption with a SHOULD.
SHOULD gives developers a guideline, which is better than nothing. The
specs contain lots of non-MUST information that nonetheless enhances
interoperability.
OTOH, if that section is removed, developers will still know by folklore
what they need to do to achieve interoperability. I prefer standards
to be explicit, rather than making developers join the club and learn
the secret handshake.
8) Sec H: "Need OIDs for DH":\xA0 PKIX X.509 Certificate and CRL Profile, sec
7.3.2 defines the use of the ANSI X9.42\xA0\xA0\xA0\xA0\xA0\xA0\xA0
dhpublicnumber OBJECT
IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046)
number-type(2) 1 } for DH keys in X.509 certs.\xA0 Can we use that OID for
CMS?
We can either refer to PKIX, or Russ can add this to the CMS spec and I can
add
it to the OIDs page. I prefer the latter, due to the problems we're having
with
PKIX. What do others want?
The "problems with PKIX" have nothing to do with defining OIDs and
specifying parameter syntax. Including DH definitions in S/MIME by value
instead of by reference may be convenient, but you must be absolutely
sure that you don't introduce inconsistencies. I think referencing
PKIX Part 1, when it gets an RFC number, is preferable.