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

[Daniel Pocock]

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.

Regards,

Daniel