On Thu, 1 Nov 2012, Simon Wilkinson wrote:
On 1 Nov 2012, at 03:42, Benjamin Kaduk wrote:
I think we can only make a weak statement in this document, and proposed as
such in my commit:
<t hangText="expiration">The time, expressed as an rxgkTime, at which
- this token expires.</t>
+ this token expires. The expiration time MAY be set administratively
+ by the server, and SHOULD reflect the expiration time of the
+ underlying GSSAPI credential.</t>
The server application has freedom to lower, or increase, the expiry time of
the underlying credential, but should take that underlying credential into
account as appropriate for the application.
I'm happy with the intent behind this, although I wonder if the wording
Okay. Does jaltman have objections to the intent behind it?
leaves the possibility that the server could set no expiration time at
all, which we obviously want to avoid.
Hmm, a fair point.
In summary (hopefully I did not miss something while reviewing the
thread), we may want to add one or more of the following constraints to
the above sentiment:
(1) the server MUST set some expiration time
(2) the server SHOULD NOT set an expiration time after the expiration time
of the underlying credential
(2) seems to be the more controversial of the two, but I would like it to
be present. This sentiment seems to parallel the snippet Russ quoted from
RFC 6717, which has "it is RECOMMENDED that the lifetime of an issued
certificate not exceed the lifetime of the predecessor Kerberos ticket
unless the implications with respect to local policy and supporting
infrastructure are clearly understood and allow it."; we can certainly use
a parallel wording if necessary to acheive consensus from this group.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
