On Wed, Feb 14, 2018 at 10:27 AM, YairE via dev-security-policy <
> Dear Ryan
> We need to refer to the points you have raised regarding the ROOT KEY – we
> must stress that the ROOT KEY and the ROOT CA are two different and
> separate entities.
> Whilst the ROOT CA does have some history the ROOT KEY was never (and
> shouldn’t be) in question.
I do not believe there is sufficient public evidence to make this
> “I hope you can understand that trust is not just based on the state of the
> world 'today', but based on everything that key has ever done and every
> bit of infrastructure that key has run on.”
> >>>> You are now moving to discuss the root key. We have started a year
> ago speaking of the CPS, than on the certificate, and now the ROOT KEY
> Allow me to declare that the ROOT KEY is intact. It is kept on an
> FIPS140-2 Level 3 HSM from its creation and always in an offline state as
> should be.
> You cannot put the key itself in any question.
You have, by virtue of the failures demonstrated.
> “We know that key has been run on deficient infrastructure, with deficient
> software, and done deficient things.”
> >>> deficient infrastructure? The HSM is the ONLY infrastructure of the
> ROOT KEY. The CA has nothing to do with the key itself. The KEY was NOT
> running on deficient infrastructure and\or software!
> “The continued public examination has continued to find and discover new
> issues since 2016.
> While remedying these issues is a crucial minimum step towards trust, it
> only gets you to a point where the current infrastructure might be suitable
> to be trusted going forward.
> Ensuring the creation of a new root, with new keys, which has never
> certified any of the deficient infrastructure, is the only way the public
> has to ensure they are not introducing additional risk to their users. “
> >>>We strongly disagree with that statement that a new KEY should be
> generated – there’s never was any problem with the KEY therefore generating
> a new one would not affect the integrity of the root as a whole.
> We think the discussion should remain on the ROOT CA which had its
> problems as discussed, and leave the KEY out of the discussion.
> However, in order to come clean and regain your trust we would agree to
> start a brand new root with a new key pair running on the new CA software
> (and BR compliant of course) but before we do so, we would like to know for
> certain that this process will be satisfactory and accepted by you.
Public trust is based on the combination of the key and the name, not the
certificate itself. The semantic quibbles aside, there should be no
question that requiring a new "root certificate" is unquestionably the same
as requiring a new subject name, with new key, to be generated.
So regardless of your position about the existing key, I hope it's clear
that a new key and new certificate should be generated.
dev-security-policy mailing list