[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

On Mon, Oct 21, 2019 at 2:01 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2019-10-21 8:35 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Mon, Oct 21, 2019 at 1:15 PM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> The BRs are supposed to be guidelines for CAs that want to issue
>> publicly-trusted certificates and for Relying Parties to be able to verify
>> these Certificates. We want good guidance to come from these documents as
>> if there were no Root programs.
>>
>
> I'm not sure who the "we" is, but this certainly is not a universally
> shared value.
>
>
> Forgive me for not being so accurate. "we" as in "the CA/B Forum". I
> thought it would be an uncontroversial statement because despite the
> different perspectives between Browsers and CAs, "we" (CAs and Browsers)
> are still working together in the Forum for the common good.
>

I think it's an inversion of priorities. Good guidance comes from Root
Programs, and the BRs reflect the commonality. The statement of objective -
BRs that exist without or independent of Root Programs - isn't a shared
value, because it's a purpose that is opposed with good security practices
by root programs.


> If the BRs were "perfect", some Root programs wouldn't need to have
>> additional requirements.
>>
>
> This is a particular problematic statement. It's extremely useful to
> understanding your perspective and the concern with 1.1, and I would hate
> that a Cleanup Ballot would become the means of litigating this, so I'd
> like to suggest we table it, for now. The best I can say is that the view
> advanced here has been a leading cause of problems, and is not one shared.
>
> However, consistent with our Bylaws, we need to emphasize that these
> requirements - and the CA/Browser Forum - does not impose anything upon any
> one. I hope you can see that the statement, as it exists, is wholly in line
> with our existing Bylaws.
>
>
> I am still not sure why you are repeating that. It is very clear from
> section 1.1. of the Baseline Requirements that "The requirements are not
> mandatory for Certification Authorities unless and until they become
> adopted and enforced by relying-party Application Software Suppliers."
>
> Are you concerned that I might be challenging that? I am not.
>

Thanks. This is clearer. Combined with your statements above about the
independence, it seemed that you were advocating a position that the BRs
should exist "as if there were no Root Programs", and that the timing
requirements should exist independent of Root Programs requirements.


> I made an observation about the last sentence of the first paragraph of
> section 1.1 of the BRs that I have seen misunderstood/misinterpreted in
> several bugs created and shared in m.d.s.p., where CAs considered the
> Baseline Requirement rules as having to be "audited" end enforced the
> moment they join a Root program. I thought this is something that needs to
> be fixed. I will probably create an issue on GitHub and keep it there until
> we can discuss in the future.
>

While I agree that such confusion exists, it's tautologically impossible to
suggest that you cannot impose requirements, but requirements are imposed
the moment these requirements exist. The requirements that exist predate
even the existence of the key material (i.e. the physical security
requirements). It's also problematic, in as much as many CAs have roots
that predate these requirements that were grandfathered in, and so a
statement that would suggest the Root Certificate(s) must always be
operated in accordance with the requirements would preclude any of those
existing roots.

There are, I think, better ways to solve the timing confusion than 1.1;
we've heard several presentations from Wayne Thayer on this at past F2F
(regarding audit lifetimes), and we've seen presentations from WebTrust to
wholly support that goal. It seems that the only thing we're missing, which
we've been missing for some time, is ETSI to move on this issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/ed68169c/attachment.html>