[cabfpub] BR Issue 7
ryan.hurst at globalsign.com
Tue Nov 6 18:43:22 UTC 2012
We believe the inclusion of caIssuers is a best practice that SHOULD be
followed given the reality we face with misconfigured servers, around 7% of
the Alexa 1m have this problem
(https://www.trustworthyinternet.org/ssl-pulse/) and the problem is much
worse for the broader internet (up to 30% in a non-scientific sampling from
Inclusion if the caIssuers helps around 60% of the browses (Chrome + IE
assuming Windows 98% of Chrome is windows) http://gs.statcounter.com/) work
around this issue.
We do not however like that the inclusion is mandated as there are cases
(such as cross certificates) where this may not be the right thing to do.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rick Andrews
Sent: Tuesday, November 06, 2012 10:07 AM
To: Paul Tiemann; Rob Stradling
Cc: public at cabforum.org
Subject: Re: [cabfpub] BR Issue 7
I agree it doesn't help security. Adding caIssuers allows a browser to
recover from a web server that fails to send the intermediate, and
successfully build a chain. The server might even neglect to send the
intermediate to save bytes on the wire, if it assumed that most clients had
The issue (as I think I've heard it from Gerv) is that browsers like Firefox
that don't try to download the caIssuers cert to form a chain end up
displaying an error that the server cert isn't trusted, although when the
user tries a browser like IE that does respect caIssuers, the server cert is
trusted. So end users blame Firefox. I guess Firefox doesn't cache and reuse
the intermediate if it's seen it before.
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Paul Tiemann
> Sent: Tuesday, November 06, 2012 10:01 AM
> To: Rob Stradling
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] BR Issue 7
> +1 to what Rob said.
> We recently were faced with the question of including AIA:caIssuer in
> a sub CA and decided against it because we couldn't identify any benefit.
> If a browser client doesn't trust the root that the sub CA came from,
> it's not likely to change its mind and begin to trust the root just
> because it can more easily locate the file online.
> On Nov 6, 2012, at 9:08 AM, Rob Stradling wrote:
> > On 06/11/12 11:15, Ben Wilson wrote:
> >> Yngve previously made a motion to make modifications to Appendix B
> >> the Baseline Requirements, as indicated by the attached. It has
> >> endorsed by Wen-Cheng of Chunghwa. Is there another endorser?
> > I (or Robin) would be happy to endorse a motion that just seeks to
> > - "With the exception of stapling, which is noted below,"
> > - "The HTTP URL of the Issuing CA's OCSP responder MAY be omitted,
> > provided that the Subscriber "staples" the OCSP response for the
> > Certificate in its TLS handshakes [RFC4366]."
> > This exception is currently present in the BRs because Comodo asked
> > it. However, we've not made use of it yet and it's looking very
> > unlikely that we would ever need to use it. IIRC, our primary
> > was the potential OCSP traffic from TLS clients that don't support
> > Stapling (i.e. Firefox!) visiting very busy websites that do support
> > OCSP Stapling. However, I'm optimistic that Firefox will gain
> > for OCSP Stapling soon.
> > However, I'm afraid we can't accept the AIA->caIssuers changes in
> > Yngve's motion for the following reasons:
> > 1. As written...
> > "Subordinate CA Certificate...authorityInfoAccess...MUST
> > HTTP URL where a copy of the Issuing (non-Root) CA's
> > be downloaded"
> > ...Yngve's motion outlaws Subordinate CA Certificates issued
> > directly
> > Root Certificates which have not been cross-certified!
> > IMHO...
> > i. issuance of such Subordinate CA Certificates should be permitted!
> > and
> > ii. such Subordinate CA Certificates should omit AIA->caIssuers.
> > 2. "it MUST contain" is unnecessarily restrictive. I'm interpreting
> > MUST contain" to mean "it MUST contain precisely <this> and nothing
> > Comodo often includes >1 caIssuers HTTP URLs, but my interpretation
> > this motion is that it requires us to include precisely 1 HTTP URL.
> > 3. We simply don't think that CAs should be forced to include
> > URLs if they don't want to include them.
> > --
> > Rob Stradling
> > Senior Research & Development Scientist COMODO - Creating Trust
> > Online
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> Public mailing list
> Public at cabforum.org
Public mailing list
Public at cabforum.org
More information about the Public