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

[Olle E. Johansson]

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

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.


/O