- From: Manuel Gil Perez <manuel@dif.um.es>
- Date: Mon, 16 Oct 2006 11:56:38 +0200
- To: www-xkms@w3.org
- Cc: Michael Wilde <michael.wilde@yahoo.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Hi Michael, Regarding to your new XKMS service, I advise you to read first the following paper about authorization using an AC: "An Authorization Mechanism for Web Services using an Attribute Certificate" http://ieeexplore.ieee.org/iel5/9088/28847/01297551.pdf Regards, Michael Wilde wrote: > Dear Manuel, dear Stephen, > > first of all, thank you for your replies. Maybe at this point I should > describe a scenario where such AC can be used. > > The underlying PKI of an XKMS service should be used to generate and > store a public key pair and issue a certificate that should be used for > signing XML documents. There already is an existing security framework > that should make use of XKMS for retrieving key pairs and their > corresponding certificates. > > The security framework is used to secure a single web service. It can be > seen as digital door keeper, that accepts XML messages and only allows > them to pass to the underlying web service if they where signed with a > certificate that includes a specific rolename. > > As suggested by Stephen this could be done using the identifier of an > application in the UseKeyWith-element. But this would not be a clean > solution. So I am thinking of implementing an own XKMS service that is > able to issue ACs as well. > > After reading your replies the attempt to integrate rolenames into ACs > that where issued by an XKMS service seems to be not a good idea, but it > is hard to change the framework that is already implemented though. > > Alternative solutions are welcome! > > > */Manuel Gil Perez/* wrote: > > 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. -- Manuel Gil Perez UMU-PKIv6 (http://pki.inf.um.es) University of Murcia, SPAIN
Received on Monday, 16 October 2006 09:57:26 UTC