[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

On Fri, Oct 18, 2019 at 5:31 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> On 18/10/2019 3:50 π.μ., Ryan Sleevi via Servercert-wg wrote:
>
>
>
> On Thu, Oct 17, 2019 at 8:18 PM Jacob Hoffman-Andrews via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> On Thu, Oct 17, 2019 at 5:14 PM Ryan Sleevi via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> On Thu, Oct 17, 2019 at 7:59 PM Jacob Hoffman-Andrews via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>>> I'm working my way through the diffs, and overall this looks great.
>>>> Thanks for putting it together. I do notice there's one important Effective
>>>> Date that's in the past but you haven't removed: 1 July 2012, the overall
>>>> effective date of the BRs. Is there any reason not to remove this one as
>>>> well?
>>>>
>>>
>>> Nope! No strong view.
>>>
>>
>> I'll work on a PR.
>>
>
> Thanks. I went and merged
> https://github.com/sleevi/cabforum-docs/commit/4ed95dc591a228cc5a1ec27842af1a36db77b3ed
>
> In the process, I spotted a few more areas of dates that have now passed
> from when we started this whole process. If someone could spot check
> https://github.com/sleevi/cabforum-docs/pull/6/files and make sure the
> requirements have stayed the same, that would be great.
>
> Of particular interest are the changes to 4.2.1; while not consistent with
> Ballot 197, it's possible that the provisions might be read that "If the CA
> obtained the data prior to 1 March 2018" rather than "If the issuance is
> prior to 1 March 2018, and the CA obtained the data...". The latter
> interpretation is what is spelled out in 197, but the former interpretation
> can be read with the way things are worded.
>
> If Wayne, Jacob, or someone interested in this section could give a spot
> check (as well as the other sections that have since passed, such as
> underscores or CP/CPS changes), that'd be great.
>
>
> This is probably something minor but I think there are Subordinate CA
> Certificates that are used as Trust Anchors in various Root Programs.
>

I'm not sure I understand this bit / what the concern is / what section
this causes issue for?


> I am also not sure what the goals for Test Certificates really are. Is the
> intent for Test Certificates to never (past, present and future) chain to a
> CA Certificate that can ever be used as a Trust Anchor? ANY Trust Anchor?
> Trust Anchors used for Publicly-Trusted Certificates (as defined in section
> 1.6.1)?
>

This again goes back to the "default-deny" vs "default-allow". The
definition of "Test Certificates" in the BRs was, at least, only intended
to be used with a specific validation method. That was the only time Test
Certificates were referenced. A Default-Deny would say "Unless I'm doing
this validation process, DO NOT issue Test Certificates". A Default-Allow
approach says "I can issue as many Test Certificates as I want, for
whatever I want, oh, and I can use them for validation as well".

We removed the validation method a while back - this was 3.2.2.4.9. Under a
"Default-Deny", there should be no test certificates. Under a
"Default-Allow", the concern is that if we remove the definition, CAs will
make up their own interpretation/definition of what a "test certificate" is.

So that's the "why keep it" - which until we resolve unambiguously in favor
of "Default-Deny", there's going to be interpretation issues.

So the second half is "What do we expect, if CAs are going to rely on this
ambiguity". The expectation is that, for a hierarchy that is-or-will-be
publicly trusted, there are zero test certificates ever issued. That is,
you can't have a root that is not yet publicly trusted, issue a bunch of
"Test Certificates" that violate a bunch of rules ('but it's ok, they're
only test certificates' - even if the BRs never say you can violate the
rules) - and then apply to have that root publicly trusted. There is at
least one CA, which is a member of the Forum, that took that interpretation
and view.

So Wayne was highlighting it would be useful to be clear here. However,
"clear" means changing the definition in a way at least one CA
(historically) disagreed with. So he was suggesting, and I agree, that it
would be better as a separate ballot, since that might be more normative
than clarity.


> I also find the first paragraph of 1.1 problematic "The requirements are
> not mandatory for Certification Authorities unless and until they become
> adopted and enforced by relying-party Application Software Suppliers". I
> don't think this meets the current expectations, but that's an issue to
> discuss separately.
>

It's exactly how it is. I totally welcome a separate discussion, but this
seems important and something we should stress. The BRs are not a thing in
and of themselves. They are an instrument for the Root Programs to use,
adopt, expand, and modify. Their legitimacy, and utility, is derived from
Root Programs that use, enforce, and audit against them (and any other
requirements they may add)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191018/86fbbc89/attachment.html>