- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Sat, 03 Dec 2005 17:01:56 +0000
- 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