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

Re: Determinig Server o Client use in XKMS

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Sun, 4 Dec 2005 13:58:14 +0000
Message-ID: <18ec59cc0512040558l7f6b64d7s8bd92e93d6343879@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "Vicente D. Guardiola Buitrago" <vicentedavid81@yahoo.es>, www-xkms@w3.org
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

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