Re: XKMS and X509v3 attributes, where to put them in?

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 <manuel@dif.um.es> 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.

--
Manuel Gil Perez

UMU-PKIv6 (http://pki.inf.um.es)
University of Murcia, SPAIN


 		
---------------------------------
Keine Lust auf Tippen? Rufen Sie Ihre Freunde einfach an.
  Yahoo! Messenger. Jetzt installieren .