-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/18/2012 10:08 AM, André Becker wrote: > 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.
OK, that's a different opinion than Thomas', so we need more discussion on the specific point of having it in -base or as an extension. Because I want to make it as painless as possible to the -base authors, I'll still publish my draft as an extension, so the -base author can just copy and paste the text if we all agree to put this in -base. As for my opinion on this subject, I agree that -base is the right place to put this, but seeing that the things we agreed on nearly 2 months ago in Vancouver still did not make it in the spec, I fear that the only path to success is an extension. > > Regards, André > > Am 18.09.2012 17:53, schrieb Marc Petit-Huguenin: 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 > - -- 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) iQIcBAEBCAAGBQJQWLO0AAoJECnERZXWan7EK/wP/3bx2C6rWnXKlUqVK8HNnKwy 91j0JMKYfMkGNV6cguWYNeARqEyOJVEgFSTKBWkMWyS3AURFeWkiU9HousYSKNUU eJ5Fpl2JAibiQfVBdoojk3kfD2qG6SUxvyXe9jRbIwI7c/uEFyZzcYX9440QRTrP Gsl2ZPCDgOTciBrrVPeZz/pzTce0u+Y89PiuWsQoH+6zP7fVqIeeEM0FvnPT2JwQ 9vnxS1jhzEvr8vemAbr0yZRUvnprMHj7o1XMdvbsiAgPgo8hXWL2jWEl0WLXaGgj gisxOFBszThV1+HZ1+u3lmCO9mgebm/KUJckk7uHCI0nqfy9XwLDEOvARNaURsyL c4Hiy6qqvPJWnEsdmL5GOtmYFmwI5OO4cuGAFbWtIzRf9yC7aMySMz+XvK6xx9sz qcuULVaHIIxpPYIS+HSwhIy7HK2X3NAfMG0vqI/1RVr2jODmHGOWWq9zqWSEWhA5 7uhxZ2gOnvl0U5g8UM8G5HdLrJO6v0an14ANvA+AuaHyiJ6VO4Y7UUQ4xWYawTR0 7nYe3HS1/twCxbP88RuMusROlG9RzMG8/w4wwFuF5UESDNWUjBHY+V1G0QNcuwqE jYKSDfhZ/UPHTYn3ieRuoJW2QUslNkp9nUCMxzPel5cZoKhYQhz5aK+j/qmjH27e vTM0VVZdOsZL5TkgVuyX =wphE -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
