Hi Marc,
thanks for the quick explanation, I'm getting your point. Even without
the OAM use case in mind I would support the idea of using an EKU to
mark RELOAD certificates as what they are. From my point of view this
definitley belongs into the base draft. And, as the EKU's purpose in the
OAM use case isn't just to allow the RELOAD-usage, but rather to forbid
others, the cleanest approach should be to make the usage of the EKU
mandatory and to mark it as critical. The additional implementation
effort seems acceptable to me.
Regards,
André
Am 18.09.2012 17:53, schrieb Marc Petit-Huguenin:
-----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
