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
frousseau(_at_)chrysalis-its(_dot_)com Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com Fax. (613) 723-5078
-----Original Message-----
From: William Whyte [mailto:WWhyte(_at_)baltimore(_dot_)com]
Sent: Monday, February 19, 2001 04:58
To: Russ Housley; stephen(_dot_)farrell(_at_)baltimore(_dot_)ie
Cc: ietf-smime(_at_)imc(_dot_)org
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