- From: Michael Wilde <michael.wilde@yahoo.de>
- Date: Tue, 17 Oct 2006 12:07:40 +0200 (CEST)
- To: www-xkms@w3.org
- Message-ID: <20061017100741.62226.qmail@web26109.mail.ukl.yahoo.com>
Hi Manuel, one could also use XKMS for registering and retrieving PKCs for authentication purposes, and an analogous technology for the communication with an AA that issues ACs for authorization purposes as sketched in the paper below. This raises the question: is there any standardized request/response protocol available for the communication with an Attribute Authority yet? Regards, Michael. Manuel Gil Perez <manuel@dif.um.es> wrote: Hi Michael, I maintain my original opinion (as I said before, it is only a personal opinion) about does not use any extension in the PKCs; for this we can use the properties of an AC. This supposes to extend the current XKMS framework to support this new type of certificate, and so provide a new kind of service for the XKMS clients. On the other hand, I agree with Stephen in to maintain the current minimum-configuration in the client side. For this, one idea is to do optional this extension to XKMS and not to be part of the XKMS core. Of course, others alternatives to support "privileges" will be welcome. Regards, -- Manuel Gil Perez UMU-PKIv6 (http://pki.inf.um.es) University of Murcia, SPAIN Quoting Michael Wilde: > Hi Manuel, > > this paper describes an attempt using a PKI as well as a PMI. For > many purposes it should be sufficient to use an extension of X509 > certificates, so one could leave the PMI away and use XKMS as PKI. > > What do you think about that? > > Regards, > Michael. > > Manuel Gil Perez schrieb: > > 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. --------------------------------- NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Received on Tuesday, 17 October 2006 10:14:32 UTC