-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Thursday, July 16, 1998 11:17 AM
To: EKR
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Section 12, take 2
Paul, the parameters sections are still wrong. As I noted
in my previous message, all the digests and rsaEncryption
take a NULL parameter. The parameter is NOT optional.
For some value of optional. We're still a bit schizophrenic
in CMS about
must and should language, since CMS is not really a protocol.
Russ chose
not to refer to RFC 2119 because of this, I think. So when we
say "optional
but implementations should emit a NULL parameter", that's
about as strong
as "MUST emit a NULL parameter but should accept with no parameters".
Unless I hear differently, I'll go with Eric's stronger wording.
[jls] this is fine with me -- in fact as stated in my previous posting my
elfs don't like the fact that we are making the paraemter absent for SHA1 as
they are only setup for doing it as NULL as in the cases of MD5.
CMS implementations must include Static Diffie-Hellman
with tripleDES. CMS
implementations may include RSA. CMS implementations may include
Static Diffie-Hellman with RC2.
What about DH with DES?
No one had asked about this. If folks want one specified,
please give an
OID and any other information needed. Out of curiousity, what
applications
do we expect to use DH-DES that aren't using one of the other three?
id-smime-cms-dh-with-tripleDES ::= { TBD }
We're defining our own OID here, but I don't like this 'NULL or
omit' stuff. We should settle on one and stick to it.
Must NULL it is.
[jls] Agreed.
For the effective-key-bits of 40, 64, and 128, the
rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important
to note that
these values are not simply the RC2 keylength. Also note
that the value 160
must be encoded as two octets (00 A0), because encoding as
one octet (A0)
is a negative number in ASN.1.
What's the input key length?
That's one for the implementors. Blake, et. al.?
[jls] There are two schools of thought at this point. There was a
discussion at the time of V2 interop where Blake and Co were generating
196-bit for RC2 keys (doing a compression step on the key material up front)
and we (Microsoft and Netscape) were generating n-bits of key material for
RC2-n. I don't know if there ever was a decision as to the reality of
having additional key material or not. In this case my vote would be to use
the first n-bits of the D-H key agreement key to encrypt the material for
all algorithms as it is easier to describe and expand later if needed that
to say generate y-bits of key material, use as many bits as your key
encryption algorithm will let you.
ContentEncryptionAlgorithmIdentifier protocol field.
Triple-DES may be an
exception here; the same identifier is used for both 2-key
and 3-key Triple
DES.
No it isn't. DES-EDE3 means 3 key 3DES.
Hmmm. Russ wrote that wording on the list many weeks ago, and
no one objected.
THis is fine with me as worded. All it means is that the 3-key triple DES
has two duplicate keys, this is often done today as saying 3-key triple DES
and providing only 128-bits of key material and then the extra bits are
duplicated as needed by the receiver. (I know that this code for receiption
is in our code base and was needed for some reason.) I would leave the
wording as is.
DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1)
member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 7}
The AlgorithmIdentifier parameter field is required and
has the structure:
CBCParameter :: IV
IV ::= OCTET STRING -- 8 octets.
Surely there is a SECSIC OID?
Surely, but this is the one that we've been using in S/MIME.
Changing it
now would break backwards compatibility. I don't think we need to take
purity of OIDs that far.
Please say with the same one we used in S/MIME V2.
--Paul Hoffman, Director
--Internet Mail Consortium