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

["Simon Blake-Wilson" <[e-mail]>]

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





[e-mail] on 03/07/2001 02:15:15 PM

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




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
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone]

-----Original Message-----
From: William Whyte [mailto:[e-mail]]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; [e-mail]
Cc: [e-mail]
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