On Wed, 31 Oct 2012, Andrew Deason wrote:
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.
Fair enough.
Where should we mention the RXGK_SERVER_ENC_TOKEN key usage?
It doesn't really seem right to bump it to rxgk-afs...
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
