[Servercert-wg] Spring is here. So is a cleanup and clarification ballot

[Ryan Sleevi]

No, this doesn't create more work for auditors on the backend - auditors
shouldn't be tailoring their responses to the root program.

You're right that they would be disclosed as findings, and the Root
Programs could decide how to address any findings they're concerned about.
I think there's plenty of existing examples about how that's worked, for
example, a number of CA misissuances that have had associated
bugs/disclosures don't warrant additional concern/attention when disclosed
in the audit.

I think the core of the concern is about whether or not it's better to have
something audited which (some) root programs may not care about, and listed
as a finding/other matter, or to have something not audited, which (some)
root programs require. There's no good hard or fast rule; some requirements
are only effective when audited, and some requirements might be able to be
imposed post-facto. I think the most likely answer for how to treat these
cases is how many root programs agree with a particular change; if the
majority of root programs agree, and a minority find it non-interesting, it
seems like it's better for everyone to place in. If a minority of root
programs find it useful, but a majority would find it
distracting/problematic, then it probably ends up as a root program
requirement.

As long as there aren't conflicting/ requirements, this works out OK. And
when there are conflicting requirements, this is an area that the CA/B
Forum is uniquely qualified to help discuss and find solutions for :)

On Thu, Apr 2, 2020 at 11:32 AM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan,
>
>
>
> If we add every possible requirement into the BRs the auditors will find
> non-compliance to some requirements for those roots in root programs that
> do not mandate that check. How do we then determine and manage which
> findings are really findings?  Does this place a lot of work on the
> auditors to know which checks are except from certain Root programs and map
> that to the root programs that the root is embedded in?
>
>
>
>
>
>
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Thursday, April 2, 2020 11:16 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Spring is here. So is a cleanup and
> clarification ballot
>
>
>
>
>
>
>
> On Thu, Apr 2, 2020 at 9:12 AM Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
> Ryan,
>
>
>
> The clean-up ballot is a good idea and I agree with the vast majority of
> your changes.
>
>
>
> For the Browser Alignment ballot, we need to be careful that we don’t
> apply rules to all Roots which are only driven by one Root program.  CAs
> *may* have roots embedded into a subset of all programs and we don’t want
> one Root program’s rules to necessarily apply to all roots in all programs.
>
>
>
> One example is ECC P-521.  This is permitted in Microsoft but not by
> Mozilla, so it should not be added to the clean-up” ballot unless MS
> changes their program.  Even then, some other programs may permit this and
> depend on it in some cases (although I have no proof this is the case).
> Same goes for changing the maximum validity period to 398 days.  We might
> consider pulling a root from the Apple trust store to permit issuance of 2
> year certificates for customers that don’t need to support Apple products.
>
>
> The same goes for signing algorithms.  It might be the case that some
> regions (China?) wants to use different algorithms not permitted by Google
> and Mozilla, but that other root programs do support and where a WT audit
> is needed.  Again, I don’t know of a specific case, but let’s be careful
> about which items we pull from the root programs and make mandatory for ALL
> root programs.
>
>
>
> I can understand and appreciate your point, although isn't this a question
> for the other Root Program(s)? That is, by having this in a Ballot, and
> having it in the BRs, we can allow Root Programs to decide whether or not
> they want to align. I think we've heard plenty from CAs where having
> alignment is beneficial and useful, especially for audits.
>
>
>
> I think the goal here should be to pull every individual item from
> individual root programs, and look to make mandatory in the BRs. If there
> are Root Programs who disagree, then certainly, removing from the BRs is
> possible. However, that does run the risk that such requirements won't be
> audited, and thus we will continue to see bifurcation of the requirements
> and the potential introduction of additional audit obligations (for
> example, a CA needing to provide both a WT audit and an AUP audit in order
> to satisfy a Root Program)
>
>
>
> In that sense, the best way to avoid that scenario is to place the most
> stringent requirements within the BRs themselves, and allow individual Root
> Programs to identify exceptions. That's because, as you note, a CA can't
> comply with all members' Programs if using P-521, so it makes sense to
> highlight that in the common profile.
>
>
>
> In any event, I'm definitely looking for feedback from other Root Programs
> regarding this. My goal is to ensure that the WebTrust for CAs / SSL
> BRs+NetSec and that the DVCP profiles continue to be useful across the
> industry, and to provide the necessary assurance (by themselves) for as
> many root programs as possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200402/e61055b7/attachment.html>