On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 07/03/2017 21:37, Ryan Sleevi wrote: >> >> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated >> Third Parties from participating in the issuance process? This would be >> effectively the same, in as much as the only capability to allow a >> third-party to participate in issuance is to operate a subordinate CA. >> >> I think it's procedurally identical to Policy Proposal 1, but it clarifies >> more explicitly that RAs are forbidden, and that all participants in the >> issuance ecosystem have a specific set of obligations. >> >> > The point is NOT to prohibit RAs (which are a good thing if done > right), but to allow revocation of certificates validated by a rogue RA. > > The setup under policy 1 would be that the actual CA holds the key and > issuance systems in its own right and under its own security audits, > while the RA only deals with the actual verification steps (such as > checking that Foo Inc is actually incorporated in country X with > official address on Bar Avenue 123 in Baz City according to official > records in the local language). > > Policy 1 is also intended for the reseller-RA combination seen in the > Symantec case, where the reseller-RA does other steps that could/should > be done by the CA directly (such as domain validation and suspicious > case double checking). > > Policy 1 may still be a problem for the truly local RA scenario where a > large number of similar RAs handle in-person verification steps for a > small geographic area (such as schemes where each city hall handles > checking photo ID of applicants as part of validation at better > than EV level). > Jakob, You basically restated what I said, except still kept the term "RA". Note that my proposal would not have eliminated the conceptual role you're describing - this is still facilitated - but it's explicitly called out as an externally operated subordinate CA, with all the attendant responsibility and audit criteria. The fact that one or more pieces of infrastructure is offered by the issuing CA is nothing new, in practice, and so the ecosystem already deals with (or fails to deal with) this case. So perhaps it's useful if you can explain why "Delegated Third Party" (since RA is overloaded to include the pre-validated domain case of an Enteprise RA, as well as to cover the case where an RA does not perform domain validation) is a useful concept to support, versus simply treating it as the well-understood role of externally-operated subordinate CA? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
