Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates

From: "Thomas Kluge" <[email-masked]>
Date: Tue, 11 Sep 2012 08:34:02 +0200

I support this as part of basic, but is should be optional. Implementors may 
either
ignore this extended key usage or check for it, but should never reject it 
if it's part
of the certificate.

Thomas

-----Ursprüngliche Nachricht----- 
From: Marc Petit-Huguenin
Sent: Friday, August 24, 2012 8:09 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Extended Key Usage for RELOAD certificates

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Sep 2012 08:23:21 -0700

On 09/10/2012 11:34 PM, Thomas Kluge wrote:
> I support this as part of basic, but is should be optional.

I now think that this should be done in a separate I-D (let's not wake the
RELOAD authors up from their cryogenic statis before October 22nd :-) ), in
the same way that RFC 5924 was done.

> Implementors may either ignore this extended key usage or check for it, but
> should never reject it if it's part of the certificate.

Hmmm.  What I would propose then is to define a mandatory-extension.  Overlay
with a configuration file containing this element MUST check for the EKU and
accept/reject the certificate based on a text similar to RFC 2924 section 5.
If the mandatory-extension is not present, then everything will work as it is
today.

If there is no disagreement, I'll prepare an Internet-Draft.  I already talked
to the PKIX people about the process to allocate a new EKU, but I'll allocate
a provisional one in my PEN for experimentation purpose.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Thomas Kluge" <[email-masked]>
Date: Thu, 13 Sep 2012 12:22:43 +0200

Sounds great. OK from my side.
Thomas

---

From: André Becker <[email-masked]>
Date: Tue, 18 Sep 2012 17:37:00 +0200

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?

Regards,
   André

Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin:
> -----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
> -----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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 18 Sep 2012 08:53:53 -0700

Hi André,

On 09/18/2012 08:37 AM, André Becker wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> 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

---

From: André Becker <[email-masked]>
Date: Tue, 18 Sep 2012 19:08:14 +0200

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:
> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 18 Sep 2012 10:47:37 -0700

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

- -- 
Marc Petit-Huguenin