- From: Tommy Lindberg <tommy.lindberg@gmail.com>
- Date: Sun, 4 Dec 2005 13:58:14 +0000
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: "Vicente D. Guardiola Buitrago" <vicentedavid81@yahoo.es>, www-xkms@w3.org
- Message-ID: <18ec59cc0512040558l7f6b64d7s8bd92e93d6343879@mail.gmail.com>
Hi Stephen - >You mean if KeyUsage == Encryption then its a server-cert and >if KeyUsage == Signature its a client cert. Yes, that's what I meant. >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). For ephemeral DH TLS cipher suites the client would be either a DSA or RSA cert so the xkms:KeyUsage==Signature approach would still seem to work. As for client generated static DH keys; isn't it possible to determine that the X.509 keyAgreement bit should be set in the resulting certificate simply by the presence of DH ds:KeyValue? (xenc:DHKeyValue could probably be used for this.) However, registration of a service generated static DH keypair appears not to be possible through a "common" URL as there is no algorithm selection mechanism in the XKMS protocol. You would also have to define suitable markup for the xkms:PrivateKey in order to be able to return the DH private key parameters. A dedicated URL seems to be the only option here. Regards, Tommy On 12/3/05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > > 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 Sunday, 4 December 2005 13:58:28 UTC