On Tue, 6 Nov 2012, Andrew Deason wrote:
On Wed, 31 Oct 2012 19:50:17 -0400 (EDT)
Benjamin Kaduk <[email protected]> wrote:
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...
The text you pushed to github seems fine (which still has
RXGK_SERVER_ENC_TOKEN right there for encrypted blobs). However, it
I realized after I sent that, that I had gotten a couple of comments
out-of-order, and that you had +1'd adding the mention of the key usage in
a different spot in the thread. Sorry for that, and thanks for the
confirmation.
says:
If the token is an encrypted blob, it should be encrypted using
the key usage RXGK_SERVER_ENC_TOKEN.
should that be a SHOULD ?
I don't think so. If we needed 2119-language, I think it would be a MUST.
But I'm not sure that we need 2119 language. We don't use it when talking
about the other key usages, if I remember correctly.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
