[cabfpub] BR Issue 7
Rick_Andrews at symantec.com
Tue Nov 6 18:07:17 UTC 2012
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 it cached.
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
More information about the Public