-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi André,
On 09/18/2012 08:37 AM, André Becker wrote: > Hi, > > I think there's a small point I don't get. You write that in the current > situation the server would need two different self-signed certificates for > the use case: One for signing reload certificates, one for signing https > client certificates. > > However, in my understanding, if you self-sign a certificate, there's no > one who tells you what to do or not to do with it. Especially, you may sign > whatever you want. So why do you need two self-signed certificates after > all? Let's say that I use only one CA to sign both certificates for RELOAD and for the Web API. In this case, a certificate signed for the Web API can also be used for RELOAD, which is probably not a problem because it will miss the SAN part (reload URI) and will be rejected. The problem is that any certificate granted for RELOAD can also been used for the Web API, e.g. used to modify the configuration file, and letting any user do this is probably not a good idea. Adding an EKU in the RELOAD certificates permits the enrollment & configuration servers to reject a connection using these certificates, without having to use a separate CA. A specialized web server could be modified to reject certificates containing a reload URI, but because standard web servers already reject an EKU that they do not understand, it is a better solution to simply define an EKU for RELOAD. > > Regards, André > > Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin: In summary, there is a > use case for RELOAD that would benefit from having an Extended Key Usage > (RFC 5280) defined and enforced by RELOAD implementations. > > Here's the use case: An enrollment server as defined by section 11.3 > generates certificates that are used by a RELOAD implementation as client > and server certificates for the purpose of establishing (D)TLS links, and > to sign RELOAD messages and data. An enrollment server will also probably > need an OAM interface, e.g. to provision the username/password, and one > natural way to design this API is by using a RESTful API over HTTPS. > Obviously access to this API must be restricted and one way of doing this > is by using client certificate. Buying a certificate that can be used to > sign client certificates is expensive, so an alternate way is to use a > self-signed certificate as CA for this purpose (the server certificate > still need to be signed by a trusted CA), which mean that there is two > self-signed CA certificates per overlay, one for signing RELOAD > certificates, and a second one for signing HTTPS certificates. Having a > RELOAD Extended Key Usage added in each RELOAD certificate and having all > RELOAD implementations verifying that the certificates used contain this > usage will permit to use the same self-signed CA certificate for signing > both RELOAD certificates and HTTPS certificates. > > Reducing the number of self-signed certificates from two to one does not > seem that useful until one is developing an application that require to > allocate a different overlay to each user. > > There is one use case where enforcing a RELOAD Extended Key Usage can be a > problem: There is usages of RELOAD where an Overlay Link Layer using > Websocket over HTTPS could be useful, in which case an existing Websocket > implementation would probably reject a connection that is using a RELOAD > certificate. That can easily be solved by using code that is specific to > RELOAD. > > So is there some support to have something this? If yes, should it be > added to -base, or developed as an extension? > - -- Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQWJkNAAoJECnERZXWan7E/OcP/3h+/qHxcTWGXANN7Y9NrjAg J0xXJ9wTqt0VaxZeMlS4sOi4SX/ecnHUebjLl69MgXlb37J8xaxlyUfDiUAPo4Ff cnmKTizYG2L783P+LdquvuZ8f7n28TrGN27L8X894QbzEORXd9G+OgrlVRYSHjmU eiq2gmqilaC77a9I9Vgqk4x0Wcft2q+rMefaWZ6vslvEvGdj3lkif4nbRJUgn/Qo NC/caWlOLV1yRkkd96XqHIw6Ucpmsk3BsfOY5F1z6ULz0d7ssKe0haQDsuoEJnsF asQiY67cqpAptTe3ovWMXd7tbVxW6uRWnuC+MM76Xh4ZHssnsX0xYDOUc6/VYzt3 KqpJMM+iHfghB8shef0TrFP9JJhC+IWr5/Ie7VyRXWK4cpiZJmjO0BoJj5FWs8Tf LHMoVWGBmzDdTqaBjQfs1yWGtWHmLiml3RK5LEZ8I30lkR8ZF2Np7PUMQ4Fuj+99 CBjfO7W+ZqQPnJVHZa/Rf3vECPsISOEdiHc2HyY0i+TBUMx1MB6+xukLzEmfnPqd 1wrPcfNo/G/sc8ngCpXtoQX1uUeB+sd+/YpUnM9qMf5GKuUVgwpvX5yBGPoW21vY DGaog2HgaVz1L0Gxh3rJnNucmRK5BJBgj8IJ1Q4ZQsiNk6HzfubFLK+uCQne8l4M m6RZUXm79wgJRqqkC57H =ILnz -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
