- From: Michael Wilde <michael.wilde@yahoo.de>
- Date: Mon, 16 Oct 2006 11:41:32 +0200 (CEST)
- To: www-xkms@w3.org
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Manuel Gil Perez <manuel@dif.um.es>
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 <manuel@dif.um.es> 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. Regards, -- Manuel Gil Perez UMU-PKIv6 (http://pki.inf.um.es) University of Murcia, SPAIN --------------------------------- Yahoo! Messenger - kostenlos* mit Familie und Freunden von PC zu PC telefonieren. --0-108779035-1160991692=:17687 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Manuel, dear Stephen,<br><br>first of all, thank you for your replies. Maybe at this point I should describe a scenario where such AC can be used.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>Alternative solutions are welcome!<br><br><br><b><i>Manuel Gil Perez <manuel@dif.um.es></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Dear Stephen,<br><br>Stephen Farrell wrote:<br>> <br>> Manuel Gil Perez wrote:<br>>><br>>> Dear Michael, XKMS folks,<br>>><br>>> X509v3 certificates cannot contain any privilege (in your case, a role <br>>> name) belongs to an end identity. A X509v3 certificate only links <br>>> statically a public key with a specific identity, not privileges. For <br>>> fix this "problem", IETF-PKIX WG defined a new structure called "X.509 <br>>> Attribute Certificate" (RFC 3281) to associate privileges to a <br>>> specific identity. The section 4.4.5 of that RFC defines how <br>>> define/include a role name.<br>> <br>> Attribute certificates existed well before the PKIX profile and are<br>> part of X.509.<br>> <br>> There is also no reason at all why a public key certificate cannot<br>> contain privilege data like roles - sometimes that's better and<br>> sometimes its better to use an AC.<br><br>I agree with you, and more since I'm talking with the XKMS and AC <br>creator :). I agree if you need to store a static/long-term role name <br>into you PKC; that is, this role name will be bound to your identity <br>during all time this is alive. But I prefer to use an AC to store this <br>role name. Identities usually grant a privilege during a short time, and <br>possibly it will be able to be granted/denied at any moment.<br><br>It is just my opinion.<br><br>>> IMHO, my advise is that we/you should try to extend the current XKMS <br>>> services to support this new kind of certificates, and so provide a <br>>> new PKIX service (privileges) to the users.<br>> <br>> Disagree.<br>> <br>> The xkms client must not have to know whether there's any X.509 PKCs or<br>> ACs anywhere, or else why are you using XKMS? So while it does make<br>> sense to think about including/linking simple privilege data to XKMS it<br>> does not, IMO, make sense to try "support" X.509 ACs in XKMS. If you<br>> want that kind of privilege handling use SAML.<br><br>Of course, SAML could be an alternative for exchanging authentication <br>and authorization data; AC could be another one, and so on.<br><br>I agree with you that the XKMS client must not have to know the specific <br>details about whether he is using a PKC or an AC; but in this sense, the <br>XKMS server does have to know the differences between them and <br>when/where use one or the other.<br><br>Regards,<br><br>-- <br>Manuel Gil Perez<br><br>UMU-PKIv6 (http://pki.inf.um.es)<br>University of Murcia, SPAIN<br></blockquote><br><p>  <hr size=1>Yahoo! Messenger - <a href=http://de.rd.yahoo.com/evt=39058/*http://de.messenger.yahoo.com >kostenlos* mit Familie und Freunden von PC zu PC telefonieren </a>. --0-108779035-1160991692=:17687--
Received on Monday, 16 October 2006 09:43:45 UTC