Cowles, Robert D. wrote:

...

-----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] Sent: Thursday, October 13, 2005 2:39 AM

...

...

Robert

perhaps the real question is, do you change your authorisation rights more or less frequently than your identifier. If more frequently, then it does not really matter if your identifier changes every year or two since you can change your authorisation rights to match the new identifier when it comes active. But if your authorisation rights are much longer lived than your identifier, then it becomes a pain to have to change these as well. However, in this case I would suggest that your authorisation rights are wrapped into the PKC, say in the subjectDirectoryAttributes extension, then they would carry over to the new identifier.

regards

David

In teresting point .. and that is precisely a problem we have with Attribute Certificates and Proxy Certificate renewal. I have been wondering if we can extend the allowed lifetime of proxy certificates so long as we can revoke their authorizaton to do anything.

Rob proxy certs are interesting since they provide several features: the ability to authenticate spawned jobs at different locations, and the ability to push authorisation attributes to remote targets. The latter feature is not needed with an attribute pull model, in which case the authorisation token lifetime is independent of the proxy cert lifetime so proxy certs could have very long lifetimes. In the push model, if what proxies push are authorisation tokens in their own right, such as signed ACs rather than straight attributes, then one or more of the ACs could be revoked whilst leaving the proxy cert and the other ACs still valid. In which case again the proxy cert could have a long lifetime. But if the proxy cert only pushes straight attributes and has a single signature, then everything has to be revoked at the same time. If proxies had a long lifetime, you would then need to revoke it when the user's authentication token had been compromised or needed to be withdrawn. So its really swings and roundabouts. The more you compress into a single token, then the less opportunity you have to partially revoke bits of it. regards David

BC

-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************