Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation

[Daniel-Constantin Mierla <[e-mail]>]

Hello,

maybe it should be split in:

1) trusting the certificate to be used for encryption, but asserting the
identity of the peer is done separately. This is the common use case
these days and the goal is to ensure the certificate belongs to the
entity owning the service by association with the main domain name.
E.g., hosted pbx providers with subdomain allocation per customer, like
custid.cloudpbx.lab. Identity of peers is ensured by other meanings like
shared secret. Here wild card certificates are very useful (with the
full left most label being the wildcard), is such case management of
certificates with full domains is getting close to impossible on large
deployments, not only painful.

2) trusting the certificate also for asserting the identity of the peer,
when it needs to match in a 1-to-1 relation. In this case wildcard
certificates are not useful, of course, but I rarely have seen it used
for this purpose.

Cheers,
Daniel

On 11.08.20 10:43, Simon MORLAT wrote:
> Hi,
>
> Thank you for all your answers, this is very helpful.
> I did not know RFC 6125. Based on these considerations, I would say
> that wildcard certificates will probably disappear for all
> applications in the next few years.
>
> Best regards,
>
> Simon
>
>
> Le lun. 10 août 2020 à 20:12, Roman Shpount <[e-mail]
> <mailto:[e-mail]>> a écrit :
>
>
>     On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         I found documentation in RFC 6125 from the “Using TLS in
>         applications” working group.
>         https://tools.ietf.org/html/rfc6125#section-7.2
>
>      
>     This section essentially says why wildcard certificates must not
>     be used and can only be supported for legacy applications. Not
>     supporting wildcard certificates does create a certain degree of
>     pain but given security risks should continue to be avoided.
>
>         Changes are done by publishing a new RFC, not with Errata.
>         That will open up a whole can of worms, but we need to open it
>         and specify how SIP over TLS should work. Like the
>         "transport=TLS” stuff and deprecating “SIPS:”.
>
>
>     One thing I've wanted for a long time is an extension which allows
>     to multiplex several DTLS connections over the same
>     protocol/address/port pair. This will allow to replicate all the
>     current SIP over UDP deployment scenarios using a secure protocol.
>     Once this is available, I would participate or author an RFC.
>
>     Best Regards,
>     _____________
>     Roman Shpount 
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda