-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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? Thanks. - -- 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) iQIcBAEBCAAGBQJQN8NAAAoJECnERZXWan7EDFkQANb3ajGoKZunezUCJRPXeWmy /pCdpWRQJSJD2gQ5pEsYmVDhGTR1jES4haC6HXB7X/fTmNGlF0CEoufRpxmUcwkW jTVCsfX2Hcb0BQcD1lKENyPgYHk9UN86QaNHBzoGIb0FPoXbfnOi8Nkvu32/pftu XQ0nbaB9bIRKtsKA3qeFWv4tPt5d59vpLK9edUcef4Gz0EWde7mf/bOalEiKdAg2 DBr1NfxHEsHZo/elIZuIHpW3JaSwZFVmZYs8M1AallCppR5CegJZEYLdJAaWkUQw wS3CYTEsi+QsTomRHyfsg+rt+3/ZzRfk5eOtnSrZctxoV8xJAF6GBZbgVTiKtnHc pA6W+1y+geAirQwGxIcKOlg5r8bSDqs07Y42yB0er0fJy+WKR9+zXKGY4DoFY28r ovFHyaE4IMNS7FvsbcfvPBEoxAZXCfMHxEDtzLTTZdYmY4BOoM0SpGwjwbfqySVf hJ4T/cHGESwT2JQvx3LMLFssXLGKj+dO3mwDYBxY3a2FvLcM5i5aiIKMYrmBsbnu DMCMLTc4Z+VpR6f30vnLRIOc9Uu8laso5Tf6eCj+lCx7ncNbSiMZyk15n5PwUL8j ITlXU5MUK0UNislPGhNynLRiqfrVAxdMGhQe+BKK3/O33CPrKxNjKcqd56EgBbQm sDXuY52VdSbFE526hGIp =q5qO -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
