W3C home > Mailing lists > Public > www-xkms@w3.org > December 2005

Re: Determinig Server o Client use in XKMS

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sat, 03 Dec 2005 17:01:56 +0000
Message-ID: <4391CF84.1020807@cs.tcd.ie>
To: Tommy Lindberg <tommy.lindberg@gmail.com>
CC: "Vicente D. Guardiola Buitrago" <vicentedavid81@yahoo.es>, www-xkms@w3.org


Hi Tommy,

Tommy Lindberg wrote:
> In the more general case where Application="urn:ietf:rfc:2246" both 
> client and server type TLS certs can be registered.  Personally, I think 
> that using the XKMS KeyUsage seems like a reasonable way to indicate 
> what type of certificate should be returned here.

You mean if KeyUsage == Encryption then its a server-cert and
if KeyUsage == Signature its a client cert. That's true I guess
and satisfies 9x% of TLS use cases, but it does leave the
TLS D-H corner cases (though they're probably not that
important).

I'd bet that service providers would still prefer the service
URL though since that way they can charge more for server certs:-)

S.

> 
> Regards,
> Tommy
> 
> 
> On 12/2/05, *Vicente D. Guardiola Buitrago* <vicentedavid81@yahoo.es 
> <mailto:vicentedavid81@yahoo.es>> wrote:
> 
> 
>     Hello,
> 
>     I've been thinking about the solution you gave me in this e-mail but I
>     want to give another situation: HTTPS.
> 
>     In HTTPS the Server/Client roles are clearly differentiated. Then, in
>     the case I want
>     to make a registation request for a Certificate to use in HTTPS, I need
>     to know if
>     it will be used as server or client.
> 
>     According your recommendation, I have to publish the service in a URL in
>     which
>     clients request for HTTPS Server Certificates and another in which
>     clients request for
>     HTTPS Client Certificates. But, in this situation, every client that
>     wants to use my service
>     have to know that depending on the requested data they have to use
>     different URLs,
>     so a client has to be aware about this kind of  peculiarities that
>     depend on
>     the concrete XKMS server.
> 
>     Are we right on this approach?? should we continue in this direction or
>     address the problem in a different way??
> 
>     Thanks a lot,
> 
>     Vicente D. Guardiola
>     University of Murcia (Spain)
> 
> 
>     Stephen Farrell wrote:
> 
>      >
>      > I guess you could either define a new UseKeyWith for a VPN g/w
>      > (is this really for tunnel mode g/w? there aren't really any
>      > clients/servers for IPsec are there.)
>      >
>      > Or, just configure different service URLs the responder, so
>      > that requests to one use profile A, whereas requests to the
>      > other use profile B.
>      >
>      > 2nd one should be easier I guess, so long as the same entity
>      > isn't playing both IPsec "roles" at different times.
>      > S.
>      >
>      >
>      > Vicente D. Guardiola Buitrago wrote:
>      >
>      >>
>      >> Hello,
>      >>
>      >> I'm implementing a XKMS Server and I've a doubt.
>      >>
>      >> My underlying PKI is based on X.509 Certificate, and the problem
>      >> raises when I have to check the KeyUsage and UseKeyWith for the
>      >> requested Key binding in the found certificates. For instance,
>     let be
>      >> a Request with a UseKeyWith for IPSEC with IP A.B.C.D  and KeyUsage
>      >> Signature and Excryption. This is a typical request, but in X.509
>      >> Certificate I need to know if the certificate is going to be used in
>      >> a Client or a Server, because the necessary extensions are different
>      >> in either situation.
>      >>
>      >> Then, the question is, how can I determine if a request is for a
>      >> Client or a Server?
>      >>
>      >> Thanks,
>      >>
>      >> Vicente Guardiola
>      >> University of Murcia (Spain)
>      >>
> 
> 
>     ______________________________________________
>     Renovamos el Correo Yahoo!
>     Nuevos servicios, más seguridad
>     http://correo.yahoo.es
> 
> 
> 
Received on Saturday, 3 December 2005 17:03:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:44 UTC