On Oct 31, 2012, at 2:32 AM, Axel Nennker <[email protected]> wrote:
> I think that https://tools.ietf.org/html/rfc2898 ( > https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the > concat-kdf from NIST. > PBKDF2 does not care whether the password consists of printable characters > or whether it is a randomly generated byte strink like our CMK. > There is no need to base64url the key/cmk. > > In the wikipedia article is a list of implementations which sounds much > better than our current rows in our crypto-algs compat-table. I only suggested base64 encoding the key as a way to get past the perceptions around the word "password". While RFC 2898 does say: Throughout this document, a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of UTF-8.) All of the implementations I've used or looked at have interpreted "password" to simply be an octet string (as per the rest of RFC 2898). - m&m Matt Miller < [email protected] > Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
