[cabfpub] BR Issue 7

[Rick Andrews]

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.

-Rick

> -----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.
> 
> Cheers,
> Paul
> 
> 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
> of
> >> the Baseline Requirements, as indicated by the attached.  It has
> been
> >> endorsed by  Wen-Cheng of Chunghwa.  Is there another endorser?
> >
> > I (or Robin) would be happy to endorse a motion that just seeks to
> remove:
> >   - "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
> for
> > 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
> concern
> > was the potential OCSP traffic from TLS clients that don't support
> OCSP
> > Stapling (i.e. Firefox!) visiting very busy websites that do support
> > OCSP Stapling.  However, I'm optimistic that Firefox will gain
> support
> > 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
> contain...the
> > HTTP URL where a copy of the Issuing (non-Root) CA's
> certificate...can
> > be downloaded"
> > ...Yngve's motion outlaws Subordinate CA Certificates issued directly
> by
> > 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
> "it
> > MUST contain" to mean "it MUST contain precisely <this> and nothing
> else".
> > Comodo often includes >1 caIssuers HTTP URLs, but my interpretation
> of
> > 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
> caIssuers
> > 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
> https://cabforum.org/mailman/listinfo/public