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

From: [email-masked]
Date: Wed, 7 Mar 2001 14:15:15 -0500

Hi William,

I also prefer the Key Derivation Function from ANSI X9.63 and I just
remembered that it is also described in Section 3.6.1 of the SECG SEC1
standard, which is freely available from the SECG web site:

http://www.secg.org/secg_docs.htm

Therefore it could be referred and used by this Internet Draft.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: William Whyte [mailto:[email-masked]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt

> >William suggests byte reversal instead, which seems ok from both
perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Wed, 7 Mar 2001 19:09:57 -0500

I also have a copyright-free description of the ANSI X9.63 KDF that I can
provide if anyone is interested in adding the I-D "wrapping".

Best regards. Simon

[email-masked] on 03/07/2001 02:15:15 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked] (bcc:
      Simon Blake-Wilson/Certicom)
Subject:  RE: WG Last Call:draft-ietf-smime-rcek-01.txt

Hi William,

Cheers,

Francois

-----Original Message-----
From: William Whyte [mailto:[email-masked]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt

perspectives.

Cheers,

William

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 9 Mar 2001 16:51:01 +0100 (W. Europe Standard Time)

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