RE: WG Last Call:draft-ietf-smime-rcek-01.txt

Magnus Nystrom <magnus@rsasecurity.com> Fri, 09 March 2001 16:18 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20106 for <smime-archive@odin.ietf.org>; Fri, 9 Mar 2001 11:18:15 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id HAA11273 for ietf-smime-bks; Fri, 9 Mar 2001 07:50:25 -0800 (PST)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA11267 for <ietf-smime@imc.org>; Fri, 9 Mar 2001 07:50:24 -0800 (PST)
Received: (qmail 35740 invoked from network); 9 Mar 2001 15:50:24 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 9 Mar 2001 15:50:24 -0000
Received: (qmail 6553 invoked from network); 9 Mar 2001 15:50:23 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.246) by spirit.dynas.se with SMTP; 9 Mar 2001 15:50:23 -0000
Date: Fri, 09 Mar 2001 16:51:01 +0100
From: Magnus Nystrom <magnus@rsasecurity.com>
Reply-To: magnus@dynas.se
To: ietf-smime@imc.org
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Message-ID: <Pine.WNT.4.31.0103091643570.696-100000@mnystrom-lap>
X-X-Sender: magnus@spirit.dynas.se
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Stephen,

I have two comments related to the discussion of the above mentioned
draft,

For the id-cek-maxDecrypts attribute, since it is an unprotected
attribute, there is no protection against anyone modifying its
value. It therefore seems as if it could be an advantage to restrain
possible values already in the specification. At the very least
I suggest it to be specified as INTEGER (1..MAX), so that recipients
won't be confused by negative values. <MAX> could be replaced by
something less, of course.

For the X9.63 KDF, I support using it instead of the PKCS #5 KDF,
since it is intended for cases like this and PKCS #5 really is
intended for something else. But for the algorithm itself, I think it
would be better if the algorithm actually was included in the
document, especially since it is quite short/compact.

-- Magnus
Magnus Nystrom
RSA Security