[Free-RTC] QR codes, mobile SIP provisioning, TLS certs

[Olle E. Johansson]

> On 08 Jul 2016, at 11:42, Daniel Pocock <daniel at pocock.pro> wrote:
> 
> 
> 
> On 08/07/16 10:21, Olle E. Johansson wrote:
>> 
>>> On 08 Jul 2016, at 10:15, Daniel Pocock <daniel at pocock.pro> wrote:
>>> 
>>> 
>>> 
>>> On 08/07/16 10:03, Olle E. Johansson wrote:
>>>> 
>>>>> On 08 Jul 2016, at 10:02, Daniel Pocock <daniel at pocock.pro> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 08/07/16 09:12, Olle E. Johansson wrote:
>>>>>> 
>>>>>>> On 07 Jul 2016, at 19:37, Daniel Pocock <daniel at 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-certificate-on-android-device
> 
> 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.

Adding a private CA in the generic key store as opposed to the app-only
keystore seems a bit more open for bad stuff happening…

/O