On Tue, Mar 13, 2018 at 11:50 AM, Ryan Sleevi <r...@sleevi.com> wrote:
> On Tue, Mar 13, 2018 at 11:26 AM, Kai Engert <k...@kuix.de> wrote:
>> On 13.03.2018 15:59, Peter Bowen wrote:
>> >> Which companies, other than Apple and Google, benefit from DigiCert
>> >> running the Manager Partner Infrastructure and from DigiCert being part
>> >> of the exclusion list?
>> > An unlimited set. Any company who purchases a certificate from
>> > DigiCert that is issued by one of the Managed Partner Infrastructure
>> > CAs benefits.
>> Thank you very much for this helpful statement.
>> I understand that previously, the trust of DigiCert Partner CAs was
>> enabled by signing from Symantec CAs.
>> Because the keys of the managed partner CAs were never controlled by
>> Symantec, it is deemed acceptable to allow these to remain trusted.
>> My conclusion is, the blog post is incomplete.
> I see. As I didn't write the blog post, I certainly can't speak to the
> intent, but I don't agree with your conclusion.
If it helps with framing the discussion any, I think one possible
misinterpretation may be reading "Distrust of Symantec" to be "Distrust of
these specific keys". Rather, the Symantec Legacy PKI (as referenced in the
consensus proposal) is the set of infrastructure, practices, policies, and
systems that comprised the failed systems, and all certificates issued by
and all information verified by that information. The Managed Partner
Infrastructure is a new set of infrastructure, practices, policies, and
systems, which issue new certificates and which verify information
Distrust in the Legacy PKI is ongoing, and the whitelist is not an
exception from that distrust - it's a reflection that these parties were
not part of the Legacy PKI. DigiCert's Managed/Transition Roots are a new
PKI, as part of the Managed Partner Infrastructure, which the transition
policy explained would be trusted.
Distrusting the keys used as the root of trust for that Legacy PKI is one
technical solution. But, as a technical solution, it distrusts more than
what the consensus proposal required or stated. Hence, whitelists - which
are simply implementations of what the consensus protocol stated. There are
other ways one could imagine accomplishing distrust in the Legacy PKI -
blacklists of intermediates or leaves, for example - that have different
technical tradeoffs and different risks (many of which, incidentally, were
discussed last year).
Perhaps that framing helps think about it - it's not necessarily the keys
being distrusted, it's everything related to those keys. Distrusting the
keys is simply a technically-sound means to accomplish that, but in doing
so, it's also necessary to carve out that which was explicitly not part of
the distrust proposal.
dev-security-policy mailing list