On 08/07/16 10:21, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:15, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
Every vendor of deskphones has their own provisioning system, they are all quite different. Some are quite effective, e.g. the way Polycom puts certificates in every phone to avoid the risk of exposing credentials during provisioning or subsequent updates.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
If you want to simplify the PKI, you simply say “here’s a fingerprint of the cert the server will give you”. Then you don’t need to validate any server chain.
If you say “here’s the fingerprint of the root CA you will have to have in your repo and will be used to sign the intermedia cert given to you, which is used to sign the server cert” you make life a bit more complex, since you have to have a way to distribute the root CA cert before you start provisioning.
If you want both, you may add a variable saying what you do - like in DNSsec.
Maybe we should also look into exchange of raw elliptic curve keys, saying “here’s the public key you will meet” to make life even more simple.
I think that allowing all these possibilities is reasonable, if the API is generic then different organizations can use it in different ways.
A third option, which I don’t prefer is to give a HTTPS url (using a well-known TLS cert assumed to be approved by all devices) where you can download the root CA cert. This is what SIP identity does. I think assuming all phones have one single CA will be wrong. Phones are not laptops. But it may work on mobile devices. Whether you can easily download a cert to the mobile device cert store remains unknown to me.
The initial target will be Android devices. Android's KeyChain API allows apps to install client certificates and root certificates and the Android OS is meant to prompt the user to confirm when this is happening. http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certifi...
Apps can also create their own key stores in the normal filesystem but these are slightly more vulnerable to manipulation and they can't be shared easily between multiple apps.
Regards,
Daniel