- From: Manuel Gil Perez <manuel@dif.um.es>
- Date: Mon, 16 Oct 2006 10:56:24 +0200
- To: www-xkms@w3.org
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Wilde <michael.wilde@yahoo.de>
Dear Stephen, Stephen Farrell wrote: > > Manuel Gil Perez wrote: >> >> Dear Michael, XKMS folks, >> >> X509v3 certificates cannot contain any privilege (in your case, a role >> name) belongs to an end identity. A X509v3 certificate only links >> statically a public key with a specific identity, not privileges. For >> fix this "problem", IETF-PKIX WG defined a new structure called "X.509 >> Attribute Certificate" (RFC 3281) to associate privileges to a >> specific identity. The section 4.4.5 of that RFC defines how >> define/include a role name. > > Attribute certificates existed well before the PKIX profile and are > part of X.509. > > There is also no reason at all why a public key certificate cannot > contain privilege data like roles - sometimes that's better and > sometimes its better to use an AC. I agree with you, and more since I'm talking with the XKMS and AC creator :). I agree if you need to store a static/long-term role name into you PKC; that is, this role name will be bound to your identity during all time this is alive. But I prefer to use an AC to store this role name. Identities usually grant a privilege during a short time, and possibly it will be able to be granted/denied at any moment. It is just my opinion. >> IMHO, my advise is that we/you should try to extend the current XKMS >> services to support this new kind of certificates, and so provide a >> new PKIX service (privileges) to the users. > > Disagree. > > The xkms client must not have to know whether there's any X.509 PKCs or > ACs anywhere, or else why are you using XKMS? So while it does make > sense to think about including/linking simple privilege data to XKMS it > does not, IMO, make sense to try "support" X.509 ACs in XKMS. If you > want that kind of privilege handling use SAML. Of course, SAML could be an alternative for exchanging authentication and authorization data; AC could be another one, and so on. I agree with you that the XKMS client must not have to know the specific details about whether he is using a PKC or an AC; but in this sense, the XKMS server does have to know the differences between them and when/where use one or the other. Regards, -- Manuel Gil Perez UMU-PKIv6 (http://pki.inf.um.es) University of Murcia, SPAIN
Received on Monday, 16 October 2006 08:57:09 UTC