[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

[Kelvin Yiu]

I agree the audit requirements needs to be clearer since section 17 of the current BR already requires all unconstrained CAs to be audited. However, the list of audit schemes is horribly out of date. For example, referencing ETSI TS 102 042 without specifying the certificate policy is insufficient. The list may contradict with browser requirements (for example, Microsoft no longer accept ISO 21188 audits). It also feels like circular reference.

Instead of each browser root program maintaining their own separate audit requirements, would it be better for the CABF as a body to maintain a list of suitable audit criteria (along with the version of the audit criteria and possibly auditor qualification information) in a separate guidelines document that browsers can reference?

I agree with Ryan that changes to the certificate profile needs to be gradual.

Kelvin



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Thursday, November 20, 2014 8:41 AM
To: Gervase Markham
Cc: CABFPub
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?


On Nov 20, 2014 6:03 AM, "Gervase Markham" <gerv at mozilla.org<mailto:gerv at mozilla.org>> wrote:
>
> On 19/11/14 23:21, Jeremy Rowley wrote:
> > I think Ryan’s suggestion is best.  If all intermediates capable of SSL
> > issuance are BR audited, then there isn’t an issue.  You still need to
> > disclose their existence in accordance with the Mozilla policy, but
> > there won’t be a need to reissue the certs.
> >
> > Plus, all the groups I contacted responded that their intermediates are
> > already compliant and wouldn’t have issues with a BR audit.  I’d support
> > moving forward with Ryan’s proposal.
>
> How does Ryan's proposal differ from Brian's?
>
> Brian's proposal, as I now understand it, is basically that we make what
> Mozilla requires (in terms of constrain or disclose-and-audit) part of
> the BRs rather than just Mozilla policy. And we define that the BRs
> cover all publicly-trusted roots, all disclosed-and-audited
> intermediates, and certificates issued from them.
>
> Gerv

Correct. That's what I proposed and explained during the Mountain View F2F. That addresses the short-term auditing gap without requiring mass reissuance by CAs and dealing with the attendant PKI complexities involved when customers fail to update their sites.

I realize mozilla::pkix leaves Firefox in a better place than it was historically. Buy there are still a number of clients (notable among them both Android and iOS, but also OS X) that are more finicky.

The changing of the certificates themselves can then be accomplished over a slower time period, and carefully.

Coupling the audit coverage clarification to a massive certificate change does not seem advisable, which is why I proposed this even prior to Mozilla adopting it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141121/c23d9c31/attachment-0003.html>