--On Monday, January 04, 2010 04:22:49 PM -0500 Derrick Brashear
<[email protected]> wrote:
The minor niggles are:
8.1. New Data Types
# define AUTHDATAMAX 1024
Are we happy that all raw authentication names will be less than 1k in
length?
Again, if anyone knows otherwise, speak up.
That's a good question. It's probably sufficient for now, but may not be
forever. On the other hand, this is the length limit on an opaque<>, which
means we can increase it later, if we're careful about it.
If a display portion is not provided, the data portion MUST NOT be used
for user display purposes.
It would seem acceptable for a GSSAPI caller, with knowledge of the
GSSAPI mechanism, to import the name contained in data, and generate its
own display name from this. I think the language here disallows that
though, so it should perhaps be modified.
It does disallow it, the issue is what happens for cases where there
is no defined single canonicalization? I it reasonable to disallow
this only in those cases?
I believe the intent was that the raw form not be displayed directly,
because it is unlikely to be human-readable. If a display form is not
provided (i.e. is empty) but the implementation understands the auth type
in question, then it should be fine to use an auth-type-specific conversion
mechanism to produce something for display. However, it is _not_ fine to
do the reverse -- the display form should never be used to derive something
used in making a security decision.
8.4.1. AuthNameToID
The "fallback" parameter to this RPC seems rather inelegant. Can you
clarify on what the use cases for this are? I wonder if it might be
cleaner to have different RPCs for the different modes?
fallback assumes implicit mappings where no explicit mappings exist
for old-style (current rxkad) principals. The goal would be for the
fileserver to fall back, thus not needing to switch to a different
call if the first returns a no mapping error.
This could be split into 2 RPCs.
Yes, I think that's best.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
