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

[Ryan Sleevi]

While I wish it was true that Section 17 covered it, the loophole is in
Section 1 - "This version of the Requirements only addresses Certificates
intended to be used for authenticating servers accessible through the
Internet"

That is, if you don't meet Section 1's Scope, surely Section 17's audit
requirements don't apply - or so the argument goes. Aligning Section 17
with Section 1 is needed, but as multiple CAs have raised during the past
meetings, that means that all of their (code signing, e-mail, etc) certs
would fall under the criteria of Section 17. So we need a way to make Scope
1 inclusive (measured by capability, not intent, like Section 17), but also
sufficiently exclusive (such as using id-kp-serverAuth) that the existing
(code signing, email, etc) intermediates don't run afoul OR are entirely
covered by the audits.

On Thu, Nov 20, 2014 at 7:06 PM, Kelvin Yiu <kelviny at exchange.microsoft.com>
wrote:

>  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> 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: https://cabforum.org/pipermail/public/attachments/20141120/4c7781c3/attachment.html