[cabfperf] Recommended Max Number of SANs in a Certificate

Thu May 15 10:54:55 MST 2014

Perhaps Ivan Ristic over at SSL Pulse will add it by request?

https://www.trustworthyinternet.org/ssl-pulse/

Much of the data that would be in the CT dataset looks to be compiled there already.

The only thing missing is the size of DN/SANs. If Ivan could drum up a box-and-whiskers chart with SAN size data (or just hostname if no SANs [even though that’s against the BRs]) we would have what we need.

Carl Mehner

From: performance-bounces at cabforum.org [mailto:performance-bounces at cabforum.org] On Behalf Of Wayne Thayer
Sent: Thursday, May 15, 2014 12:32 PM
To: Silva, Marcelo; Jeremy Rowley; 'Ryan Hurst'
Cc: performance at cabforum.org
Subject: EXTERNAL: Re: [cabfperf] Recommended Max Number of SANs in a Certificate

Ryan Sleevi pointed out that this data is available in Google’s CT datasets, so what we really need is for someone to analyze it. Are there any takers?

From: Wayne Thayer
Sent: Thursday, May 01, 2014 1:26 PM
To: 'Silva, Marcelo'; Jeremy Rowley; 'Ryan Hurst'
Cc: performance at cabforum.org<mailto:performance at cabforum.org>
Subject: RE: [cabfperf] Recommended Max Number of SANs in a Certificate

Will someone volunteer to compile this data?

From: Silva, Marcelo [mailto:masilva at visa.com]
Sent: Thursday, May 01, 2014 11:27 AM
To: Jeremy Rowley; 'Ryan Hurst'; Wayne Thayer
Cc: performance at cabforum.org<mailto:performance at cabforum.org>
Subject: RE: [cabfperf] Recommended Max Number of SANs in a Certificate

+1. I agree with Rick on the idea to create a matrix with those information so that we would have consistent information to provide any recommendation, if that is the case.

Marcelo Silva

From: performance-bounces at cabforum.org<mailto:performance-bounces at cabforum.org> [mailto:performance-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, May 01, 2014 2:13 PM
To: 'Ryan Hurst'; 'Wayne Thayer'
Cc: performance at cabforum.org<mailto:performance at cabforum.org>
Subject: Re: [cabfperf] Recommended Max Number of SANs in a Certificate

+1 to this.  I like the idea of a table showing size ranges.

From: Ryan Hurst [mailto:ryan.hurst at globalsign.com]
Sent: Thursday, May 1, 2014 11:59 AM
To: Wayne Thayer
Cc: Rick Andrews; Jeremy Rowley; performance at cabforum.org<mailto:performance at cabforum.org>
Subject: Re: [cabfperf] Recommended Max Number of SANs in a Certificate

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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> [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<mailto: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> [mailto:performance-bounces at cabforum.org] On Behalf Of Wayne Thayer
      Sent: Thursday, May 1, 2014 10:56 AM
      To: performance at cabforum.org<mailto: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<mailto:Performance at cabforum.org>
      https://cabforum.org/mailman/listinfo/performance

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/performance/attachments/20140515/0c99930e/attachment-0001.html 