[cabfperf] Recommended Max Number of SANs in a Certificate

[Ryan Hurst]

No it's a recommendation to look at the problem differently.

I think that most people don't know how much data goes into a certificate.

Some to crazy with policy CAs which slow down SSL for many of the same reason (too much data).

We could look at all of the certificates that we've issued figure out things like average length/size hostname, DN, RSA keys, ecc keys, etc.

We could provide that in the form of a table with size ranges. That could be used to estimate certificate size with the chosen profiles.

And then do a similar exercise for maximum available size in a TLS negotiation per implementation (assuming recommended settings).

And the recommendation would be to find profiles that stayed within those limits.


Ryan Hurst

Sent from my phone, please forgive the brevity.

> On May 1, 2014, at 10:51 AM, Wayne Thayer <wthayer at godaddy.com> wrote:
> 
> This seems like an argument for doing nothing. Yes, the number of SANs is only one component of the size of the cert. The size of the cert is only one component of the size of data in the handshake, and the size of data in the handshake needs to be considered relative to the TCP initcwnd. Taking all of these variables into account is beyond the expertise of most certificate subscribers and server operators.
>  
> Can we recommend a maximum number of SANs if we do so in the context of other recommendations for certificate size such as the number of SCTs, removing duplicate fields and extraneous data, choosing appropriate key size, etc? Should we also attempt to define a max certificate size? If so, any thoughts on what that should be?
>  
> From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
> Sent: Thursday, May 01, 2014 10:32 AM
> To: Ryan Hurst; Wayne Thayer
> Cc: Jeremy Rowley; performance at cabforum.org
> Subject: RE: [cabfperf] Recommended Max Number of SANs in a Certificate
>  
> +1 I was just composing a similar reply. For example, an EV cert that will need 3 SCTs may overflow the initial congestion window with 25 SANs. Better to focus on the final size of the cert.
>  
> From: Ryan Hurst [mailto:ryan.hurst at globalsign.com] 
> Sent: Thursday, May 01, 2014 10:30 AM
> To: Wayne Thayer
> Cc: Rick Andrews; Jeremy Rowley; performance at cabforum.org
> Subject: Re: [cabfperf] Recommended Max Number of SANs in a Certificate
>  
> I don't think making a recommendation for setting a maximum number of SANs is really appropriate. At least in the context of performance.
>  
> What's important when thinking about the size of the certificate is not the size of the certificate itself but how much other data is being sent in the TLS exchange.
>  
> 25 SANs may very well be fine in one case and be a problem in another.
>  
> It's also highly dependent on the length of the domain names themselves.
>  
> I would add that the complexity of the certificate chain has a much larger impact then additional SANs; for example including one intermediate will add it least a K.
>  
> Ryan Hurst
>  
> Sent from my phone, please forgive the brevity.
> 
> On May 1, 2014, at 10:18 AM, Wayne Thayer <wthayer at godaddy.com> wrote:
> 
> This working group is only planning to make recommendations. Is 25 SANs per certificate a good recommended max that is both practical and reasonable from a performance perspective?
>  
> From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
> Sent: Thursday, May 01, 2014 10:15 AM
> To: Jeremy Rowley; Wayne Thayer; performance at cabforum.org
> Subject: RE: [cabfperf] Recommended Max Number of SANs in a Certificate
>  
> I think imposing a maximum is a bad idea. Some customers want 100 or more SANs. I’m sure they’re aware of the performance implications, yet they want them anyway. I can’t think of a good security argument for denying them. So if it’s just performance, I think we must stick to recommendations for best performance, not requirements.
>  
> From: performance-bounces at cabforum.org [mailto:performance-bounces at cabforum.org] On Behalf Of Jeremy Rowley
> Sent: Thursday, May 01, 2014 9:58 AM
> To: 'Wayne Thayer'; performance at cabforum.org
> Subject: Re: [cabfperf] Recommended Max Number of SANs in a Certificate
>  
> We currently recommend a maximum of 25.  However, we have some customers that need more because of their particular server configuration.  I think it’d be more productive to discuss individual certificate components than adopt a total size limitation and let the CAs figure out how to make it work.
>  
> From: performance-bounces at cabforum.org [mailto:performance-bounces at cabforum.org] On Behalf Of Wayne Thayer
> Sent: Thursday, May 1, 2014 10:56 AM
> To: performance at cabforum.org
> Subject: [cabfperf] Recommended Max Number of SANs in a Certificate
>  
> Certificates with dozens of SAN entries have become common, in part due to the popularity of CDNs that use these certs to conserve scarce IPv4 addresses. This data can increase the size of the certificate by 25% or more. Should we recommend a maximum number of SANs in a certificate? If so, what should that number be? Or should we look at the total size of the certificate rather than individual fields?
>  
> Thanks,
>  
> Wayne
> _______________________________________________
> Performance mailing list
> Performance at cabforum.org
> https://cabforum.org/mailman/listinfo/performance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/performance/attachments/20140501/67a61df3/attachment-0001.html