On Wed, 31 Oct 2012 18:40:36 -0400 (EDT) Benjamin Kaduk <[email protected]> wrote:
> Andrew's text is fine with me (with the caveat that we would > still not refer to the RXGK_SERVER_ENC_TOKEN key usage value if that > text is used), but I'd also be fine with adding some bit about the > specification being for the properties of the token, not the > particular mechanism used (maybe there is a mechanism other than > encryption or lookup table, who knows). Yes, who knows, and in my opinion "who cares". Any mechanism is going to have operations analagous to encrypt and decrypt; I think it's pretty obvious from the draft what you're supposed to do in such situations. However, I don't think it's difficult to generalize this a bit more. My off-hand guess at some text: "... It is assumed that such applications will conceptually 'encrypt' a token by somehow associating the 'encrypted' token with the associated unencrypted data, and will 'decrypt' an encrypted token by looking up that association to find the unencrypted data." But I don't think it is worth spending much time on this; this seems very unlikely to result in any practical issues. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
