[cabfperf] Recommended Max Number of SANs in a Certificate
Yngve N. Pettersen
yngve at spec-work.net
Thu May 15 19:19:32 MST 2014
Hello all,
I took a quick look in my TLS Prober database, which contain about 3
million certs collected in the past 4 years or so. The sample set is
biased toward Alexa top million sites, about 500K servers sampled in each
scan.
The highest number of SAN entries in a certificate in my list was 1108,
most (that have any) have less than 25 (99% of those with SAN entries; 90%
have 1 or 2 entries, 95% have 5 or less). (2/3 of the sample did not have
SAN entries, and was not counted). I'll note though that there are
probably going to be few servers that require a lot of names in a
certificate, and those would not change the numbers much.
The longest name entry was 81 characters, almost all are less than 50
characters and the majority (85%) less than 25 characters long.
The longest concatenated string length of a SAN section was ~18K, most
less than 100 characters.
Almost all subject DNs are 500 bytes or less, the majority (3/4) is 200
bytes or less. There are 160 in the sample with length of 10-20KB
The majority (7/10) of certificates are between 1000 and 2000 bytes long,
with most of the rest (less than 3/10) being 500-1000 bytes (This does
include non-CA issued certificates). About 1500 certs are 10 or more, one
was 50+KB
On Thu, 15 May 2014 19:54:55 +0200, Mehner, Carl <Carl.Mehner at usaa.com>
wrote:
> 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
>
--
Sincerely,
Yngve N. Pettersen
Using Opera's mail client: http://www.opera.com/mail/
More information about the Performance
mailing list