Subject: [P2PSIP] Extended Key Usage for RELOAD certificates

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 24 Aug 2012 11:09:06 -0700

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-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug