On 04/04/2017 05:30, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


So why does Mozilla want disclosure and not just a blanket X on a form
stating that all SubCAs are adequately audited, follow BRs etc.?

What use does Mozilla have for any of that information if not to act on
it in relation to trust decisions?


The incorrect part is that you're assuming it's a blocking process. It's
not - it's entirely asynchronous. Us folks who actually review CP/CPSes are
barely handling it at the root layer, let alone the intermediate. That's
why the CCADB - and the automation being developed by Microsoft and the
standardization I've been pushing - is key and useful.

The tradeoff has always been that CAs are granted the flexibility to
delegate, which intentionally allows them to bypass any blocking browser
dependencies, but at the risk to the issuing CA that the issuing CA may be
suspended if they do an insufficient job. It's a distribution of workload,
in which the issuing CA accepts the liability to be "as rigorous" as the
browser programs in return for the non-blocking flexibility of the
subscriber CA. In turn, that risk proposition (of the issuing CA) is offset
by the cost they impose on the subscriber CA.


That permitted asynchronicity was never clearly stated, and I was led
astray by explicit language prohibiting issuance by the SubCA before
the moment of disclosure, which is an explicit synchronization
requirement.  Once it is clear that it is permitted to disclose after
most *other* associated risks begin, then the entire problem goes away.

That simple inconsistency is what led to all this.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to