>> The amount of "security" in the redaction is ENTIRELY up to the >> redactor. Given this spec, the redactor is welcome to use HMAC if they >> want to -- if they or their lawyers think they need that level of >> confidence that it can't be deciphered. Depending upon the redactor's >> sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC, >> or, hey, just base64-encode the plain-text string if all you want is to >> keep it away from idle eyes. >> >> It makes no sense for this spec to declare anything in this regard. > > Does that mean, in Section 2, we could replace steps 1 through 4 with > something > more generic, like simply "Apply any isomorphic transformation to each > instance > of private data in this message", and suggest a range of possibilities from > base64 > to rot13 to CRC32 to H to HMAC, depending on the site's needs, perhaps with > requisite admonition to be aware of the strengths and weaknesses of each? > > That would mean Section 3 becomes a lot simpler as well.
That would work for me. Barry _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
