Google Plan for Symantec posted

[Gervase Markham]

Hi m.d.s.p.,

Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan has significant overlap with
Mozilla's draft proposal here:
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.

Assuming she does, this will effectively turn into a 3-way conversation
between Symantec, Google and Mozilla, to iron out the details of what's
required, with the Google proposal as a base. (Which I'm fine with as a
starting point.)

Comments are therefore invited on what modifications to the plan or
additional requirements Mozilla might want to suggest/impose, and
(importantly) why those suggestions/impositions are necessary and
proportionate.

Gerv


-------- Forwarded Message --------
Subject: Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date: Fri, 19 May 2017 10:27:41 -0400
From: Ryan Sleevi <rsl...@chromium.org>
Reply-To: rsl...@chromium.org
To: blink-dev <blin...@chromium.org>
CC: Ryan Sleevi <rsl...@chromium.org>, awha...@chromium.org



Overview / Background

Here's an update on the discussions about Symantec-issued certificates
and the steps Chrome is proposing to move forward. Thank you to
everybody who has contributed to the discussion so far.


On May 12, members of the Chrome team met with Symantec to discuss the
set of concerns and our proposed remedy for them. These discussions were
an expansion on a proposal previously shared with Symantec in April, and
later shared on the mozilla.dev.security.policy list
<https://groups.google.com/d/msg/mozilla.dev.security.policy/lOHrTr97Qx0/2IkcSGq9AQAJ>.


When the original Intent to Deprecate was posted, I proposed
<https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ>a
plan that tried to best address issues we were aware of and provide a
long-term path for comprehensive protections. We received a lot of great
feedback from the Blink and wider PKI communities regarding the impact
this plan would have and further issues to consider. In light of this
feedback, we would like to propose a new plan that we believe ensures
users are sufficiently secured while trying to minimize disruption to
site operators, and providing an objective and reasonable path forward
for those that have critical dependencies on certificates that chain to
Symantec-operated roots.


We want to share an overview of this plan with the broader community,
with more specific, detailed requirements at the end. The high-level
overview of the plan is:

*

Symantec will modernize their platform and PKI dedicated to website
certificate issuance. Symantec has previously posted

<https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue>
that this in their current roadmap, and we require that the
modernized platform adheres to best practices for CAs in security,
design, and process as part of that modernization process.

*

Until the modernized platform is ready and accepted into major trust
stores, certificates would need to be issued through one or more
independently operated third-party CAs (aka “Managed CAs”) that
Symantec would partner with.

*

The Managed CAs could be cross signed by an agreed upon set of
existing Symantec roots, to take advantage of the existing roots'
ubiquity in trust stores.

*

EV certificates can be issued by Managed CAs, provided that they
meet the validation requirements.

*

Validity period of new certificates can be up to 39 months, or to
the maximum allowed by Chrome for all CAs (currently specified in
the Baseline Requirements and EV Guidelines), provided that a
Managed CA fully revalidates the information. During a bridge
period, Managed CAs can reuse existing validation information but
lifetimes must be limited to 13 months.

*

Existing certificates issued on or after June 1st 2016 would still
be trusted, provided they comply with the Chrome CT policy. EV
certificates issued on or after this date will continue to be
granted EV treatment.

*

Existing certificates issued before June 1st 2016 would go through a
phased distrust based on notBefore dates.

*

Chrome will offer an Enterprise Policy to allow older certificates
to be trusted to help with migration to the new PKI.

While the plan is not final, we believe it is converging on one that
strikes a good balance of addressing security risk and mitigating
interruption. We still welcome any feedback about it, as prior feedback
has been valuable in helping shape this plan.


Transition to a New Symantec PKI

Chrome will require that by 2017-08-08 all new Symantec-chaining
certificates be issued by independently operated third-parties (aka
“Managed CAs”).


Chrome will implement a check, on-or-after 2017-08-08, to enforce this
by ensuring that the certificate chain contain a whitelist of
intermediates (independently operated sub-CAs or the Managed CAs).


If a Managed CA has fully revalidated the information, the validity
period of new certificates can be up to the maximum allowed by Chrome
for all CAs, which is currently specified as the maximum allowed by the
Baseline Requirements and EV SSL Guidelines.


During a transition period, validation information can be reused,
provided that the certificate is issued by the new infrastructure.
However, the validity period of such certs must be no longer than 13 months.


If Symantec needs this flexibility, the following deadlines apply:

*

2017-08-08 - Certificates must be issued by the Managed CA, but can
re-use existing validation information (up to the limits imposed by
the Baseline Requirements).

*

2017-11-01 - Certificates must be issued and have domains
revalidated by the Managed CA, but can use re-use existing
organization validation information (up to the limits imposed by the
Baseline Requirements).

*

2018-02-01 - Certificates must be issued and have all validation
performed by the Managed CA.


The use of existing or new validation information in a certificate
should be signalled by using new OID in the Certificate Policies
extension. See the Technical Details section for more information. If
the managed CA is unable to validate the information by such milestones,
then such certificates will not be able to be issued or trusted.


Existing Certificates

Chrome will continue to trust certificates issued after 2016-06-01,
provided they are “CT Qualified” as defined in the Chrome CT Policy
<https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency>.


Enterprise Chrome users will be given a policy to allow certificates
issued before 2016-06-01. This will give enterprise administrators the
ability to control Chrome behavior for their organizations. This can be
specified both at device-level
<https://support.google.com/chrome/a/answer/187202?hl=en>as well as at
user-level <https://support.google.com/chrome/a/answer/2657289?hl=en>.


We’re proposing a phased distrust of all website certificates issued
prior to 2016-06-01, which is the date in which Chrome both required and
enforced Certificate Transparency. This provides a degree of assurance
for site operators that certificates issued for the improper domain have
a reasonable chance of being detected. With this, our goal is to attempt
to minimize disruption to site operators, ensure reasonable notice of
these changes, and avoid particularly sensitive holiday disruptions.
These plans represent target dates, which may need to be adjusted based
on interoperability or compatibility risk or additional information
coming to light that may accelerate such distrust.

*

On 2017-08-31, no longer trust any certificate whose notBefore was
prior to 2015-06-01. This corresponds with an expected Chrome 62 date.

*

On 2018-01-18, no longer trust any certificate whose notBefore was
prior to 2016-06-01. This corresponds with an expected Chrome 65 date.


Technical Details


Operations

*

These sub-CAs must be operated by a non-affiliated organization that
operates roots currently trusted in the Android and Chrome OS trust
stores that have been trusted for a period of at least two years.

*

The non-affiliated organization must accept full responsibility for
the operation of these sub-CAs and agree that any misissuance from
these sub-CAs will be treated as if it was misissuance from any of
the other CAs the organization operates. Similarly, any misissuance
from the other CAs the organization operates will be treated as if
it was misissuance from these sub-CAs. Because the basis for trust
in these intermediates will be based on chaining to the existing
Symantec root certificates, rather than to a different
organization’s CA certificates, Symantec must also accept
responsibility for the operation of these sub-CAs and agree that any
misissuance from these sub-CAs will be treated as if it was
misissuance from any of the other CAs that Symantec operates.

*

Symantec and its affiliates must not participate in any of the
information verification roles permitted under the Baseline
Requirements, such as Delegated Third Parties, including that of
Enterprise RAs, or as Validation Specialists. That is, the
non-affiliated organization bears full responsibility to perform all
information verification controls related to the issuance of the
certificates. Symantec and its affiliates may, however, seek to
collect and aggregate all of the information as part of the
Certificate Request process in order to expedite and simplify the
verification process.

*

These sub-CAs must not be used to certify any Symantec-operated or
-controlled CAs, but may themselves be certified by existing
Symantec-operated or -controlled CAs. That is, they can be
cross-signed by the existing infrastructure, but they must not
cross-sign any of the existing infrastructure or certificates.

*

No Delegated Third Parties shall be used to perform the information
verification functions of domain verification (Section 3.2.2.4 of
the Baseline Requirements) or IP address verification (Section
3.2.2.5 of the Baseline Requirements)

*

The Certificate Policy and Certification Practice Statements
(CP/CPS) for the sub-CAs may use Symantec’s domains for purposes of
CAA verification, as they are operating on behalf of Symantec.


Audits

*

Within 90 days of the first certificate being issued by any of these
sub-CAs, the operating organization shall provide a Period of Time
audit report according to the “Trust Service Principles and Criteria
for Certification Authorities” and the “WebTrust Principles and
Criteria for Certification Authorities - SSL Baseline with Network
Security.” If Symantec desires for these sub-CAs to be recognized as
capable of issuing EV certificates, Symantec shall also provide a
“WebTrust Principles and Criteria for Certification Authorities -
Extended Validation SSL.” All audits shall use the current version
of the criteria appropriate for the audit engagement date. The
period of time must include the moment of the Key Generation
Ceremony, must not exceed 120 days in duration, and must not be less
than 30 days in duration. Note that 90 days represents when the
report shall be provided, not the end of the period of time.

*

The audit report scope must include all Principles and Criteria and
include all locations in which the key material exists. If a
Principle or Criteria is excluded from the scope due to the
non-performance of that function, the audit report and management’s
assertion letter must attest that no organizations, including the
operating organization, performed that role or function for the
Period of Time under audit.

*

An unbroken sequence of such audit reports shall be posted publicly
and provided to Google no more than 90 days after the conclusion of
the audit period. For the first year following the issuance of the
first certificate, the audit period shall not exceed 90 days. For
the second year, the audit period shall not exceed 6 months. For
third and subsequent years, the audit period shall not exceed 12 months.

*

Any and all subordinate CAs certified by these sub-CAs must be
covered by the same CP/CPS, management’s assertion, and audit
reports as the sub-CA itself. That is, any sub-CAs beneath these
sub-CAs must be part of the same infrastructure and operation of the
non-affiliated organization.


Certificate Details

*

In order to be trusted, issued certificates must be “CT Qualified”,
as defined in the Certificate Transparency in Chrome Policy

<https://www.chromium.org/Home/chromium-security/certificate-transparency>.

*

Each certificate must clearly identify the degree of information
that has been revalidated. To accomplish this, we propose that
Symantec make use of three newly-defined OIDs, to be allocated by
Symantec, and to be placed within the Certificate Policies
extension, with a distinct OID for each of the following scenarios:

o

Issued on new infrastructure, but reusing existing information
previously validated or obtained by Symantec.

+

Certificates bearing this policy OID MUST NOT be valid for
longer than 400 days.

o

Issued on new infrastructure, with domain information having
been validated by the organization operating the Managed CA for
Symantec, but containing and reusing organizational information
validated previously by Symantec.

+

Certificates bearing this policy OID MUST NOT be valid for
longer than 400 days.

+

As DV certificates do not contain organization information,
no DV certificates should bear this policy OID.

o

Issued on new infrastructure, with all information contained
having been validated by the organization operating the Managed
CA for Symantec.

+

Certificates bearing this policy OID MUST NOT be valid for
longer than the maximum time permitted by Chrome for all CAs
at the time of issuance, which is currently defined within
the CA/Browser Forum’s Baseline Requirements.


Transition to New Infrastructure

*

Until such a time as Symantec’s new infrastructure has been accepted
as trusted for TLS server certificate issuance in the root stores
used by the Stable version of Chrome on the most recently released,
generally available version of the supported OS platform Chrome is
running on, the sub-CAs must continue to be operated according to
the requirements outlined here.

o

At this time, this includes the root stores of Microsoft (Chrome
on Windows), Apple (Chrome on macOS and Chrome on iOS), Mozilla
(Chrome on Linux) and Google (Chrome on Android and Chrome on
Chrome OS). And would include any future Google root store
program used by Google products and services.

*

In continued collaboration with CPA Canada and the WebTrust Task
Force in determining the feasibility and appropriateness of such
reports, as part of the determination for acceptability of the new
infrastructure, Symantec may be requested to provide a report on
controls at the Certification Authority that includes a description
of the auditor’s tests of controls and results, covers a period of
time, and includes a description of the system. The intended users
of the report must include persons who assist in decisions related
to the trusted status of Certification Authorities within Chrome and
Google products.

--
You received this message because you are subscribed to a topic in the
Google Groups "blink-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/chromium.org/d/topic/blink-dev/eUAKwjihhBs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
blink-dev+...@chromium.org
<mailto:blink-dev+...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYUvGZA1-LBpYBWaAAz_MopmO9SivWiDJGS1ousS3-srg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYUvGZA1-LBpYBWaAAz_MopmO9SivWiDJGS1ousS3-srg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Steve Medin]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, May 19, 2017 11:42 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [EXT] Google Plan for Symantec posted
>
> Hi m.d.s.p.,
>
> Google have posted their updated plan for Symantec in the blink-dev forum
> (copied below).

Posting on behalf of Symantec.

Google’s latest proposal follows collaborative and constructive community discussions. Our goal has been to reach a solution that minimizes disruption for our customers and is in the best interests of the entire Internet community.

While there remain details to be considered, we believe Google has put forth a new proposal that limits business disruption for customers as compared to prior proposals. Notably, Google’s revised proposal would not require Symantec to move to shorter-term validity certificates beyond what was approved by the CA/B forum in Ballot 193 for all CAs and Symantec’s Extended Validation certificates would remain intact. Given the potential impact of any changes that might be implemented, we are carefully reviewing this proposal and will respond shortly with feedback for the community’s consideration.

We thank our customers and the community for their patience and participation in this important discussion.

[Kathleen Wilson]

On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:
>
> I have passed that document to Kathleen, and I hope she will be
> endorsing this general direction soon, at which point it will no longer
> be a draft.
>
> Assuming she does, this will effectively turn into a 3-way conversation
> between Symantec, Google and Mozilla, to iron out the details of what's
> required, with the Google proposal as a base. (Which I'm fine with as a
> starting point.)
>
> Comments are therefore invited on what modifications to the plan or
> additional requirements Mozilla might want to suggest/impose, and
> (importantly) why those suggestions/impositions are necessary and
> proportionate.
>

Gerv, thank you for all the effort you have been putting into this investigation into Symantec's mis-issuances, and in identifying the best way to move forward with the primary goal being to help keep end-users safe.

I fully support requiring Symantec to set up a new PKI on new infrastructure, and to transition to it in phases, in order to minimize the impact and reduce
the risk for end-users.

I think the general direction is correct, but I think there are a few details to be ironed out, such as:

- What validity periods should be allowed for SSL certs being issued in the old PKI (until the new PKI is ready)? I prefer that this be on the order of 13 months, and not on the order of 3 years, so that we can hope to distrust the old PKI as soon as possible. I prefer to not have to wait 3 years to stop trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued this year.

- Perhaps the new PKI should only be cross-signed by a particular intermediate cert of a particular root cert, so that we can begin to distrust the rest of the old PKI as soon as possible.

- I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this.

Thanks,
Kathleen

[Jakob Bohm]

On 19/05/2017 22:04, Kathleen Wilson wrote:
> On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:
>>
>> I have passed that document to Kathleen, and I hope she will be
>> endorsing this general direction soon, at which point it will no longer
>> be a draft.
>>
>> Assuming she does, this will effectively turn into a 3-way conversation
>> between Symantec, Google and Mozilla, to iron out the details of what's
>> required, with the Google proposal as a base. (Which I'm fine with as a
>> starting point.)
>>
>> Comments are therefore invited on what modifications to the plan or
>> additional requirements Mozilla might want to suggest/impose, and
>> (importantly) why those suggestions/impositions are necessary and
>> proportionate.
>>
>
>
> Gerv, thank you for all the effort you have been putting into this investigation into Symantec's mis-issuances, and in identifying the best way to move forward with the primary goal being to help keep end-users safe.
>
> I fully support requiring Symantec to set up a new PKI on new infrastructure, and to transition to it in phases, in order to minimize the impact and reduce
> the risk for end-users.
>
> I think the general direction is correct, but I think there are a few details to be ironed out, such as:
>
> - What validity periods should be allowed for SSL certs being issued in the old PKI (until the new PKI is ready)? I prefer that this be on the order of 13 months, and not on the order of 3 years, so that we can hope to distrust the old PKI as soon as possible. I prefer to not have to wait 3 years to stop trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued this year.
>

I think this can be solved by having either the new Symantec PKI (if
trusted) or some other trusted CA cross sign the Managed SubCA, then
including that cross cert in the P11 object in Mozilla products.

This would disconnect the new certs (even if they have 35 months left)
from the old Symantec PKI for any client that includes the cross certs
in its standard store, allowing the old CA certs to be removed in the
very same release (unless of cause there are pre-transition certs that
should still be trusted).

> - Perhaps the new PKI should only be cross-signed by a particular intermediate cert of a particular root cert, so that we can begin to distrust the rest of the old PKI as soon as possible.
>

Again, the idea would be that once the new PKI cross signs the
transitional managed SubCAs, root stores can ship the new root CAs and
the new cross certs for the SubCAs while instantly distrusting the old
PKI. In other words the Managed/transitional SubCAs would serve the
role of your proposed "particular intermediate cert".

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this.
>

That seems to be a matter of debate. I have been arguing the same
point without success.



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

[Jakob Bohm]

> ...
>

The following was written prior to seeing Kathleen's post, so it does
not consider her reservations with some key parts of the
Google/Symantec plan. However it is mostly independent anyway, as it
is about how to extend the WebPKI considerations to other PKI areas
that affect Mozilla and/or the community.

Suggested trivial changes relative to the proposal for Mozilla use:

1. Replace or supplement every occurrence of "Google" by "Mozilla".

2. Replace or supplement every occurrence of "Chrome" by "Firefox,
Thunderbird and other Mozilla products". State that the references to
non-Mozilla root stores does not apply to Mozilla.

Suggested reasonable changes based on my guesses at what would benefit
Mozilla Foundation and Mozilla Inc directly or as champions of the
relying parties community at large:

3. All non-expired Symantec issued certificates of any kind (including
SubCAs and revoked certificates) shall be CT logged as modified by #4
below. All Symantec referenced OCSP responders shall return SCTs for
all such certificates, if possible even for revoked certificates. This
also applies to expired certificates that were intended for use with
validity extending timestamping, such as the code signing certificate
issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f
c9 71 67 0e 73 e3 69 c7 91. Independent parties or root stores may at
their option use this data to generate public trust whitelists.

Necessity: Whitelists in various forms based on such CT log entries,
as well as the SCTs in OCSP responses can provide an alternative for
relying parties checking current certificates even if the cleanup at
Symantec reveals a catastrophic breach during the past 20+ years.

Proportionality: This should be relatively easy for the legitimate
certificates issued by Symantec, since the underlying data is still
used for OCSP response generation.

4. All stated requirements shall also apply to S/MIME certificates.
Except that CT logging shall be redacted as follows: Symantec shall
instead submit to at least two independent CT logs who accept that,
S/MIME TBScertificates with the CN, L, street, serialnumber and mailbox
parts, as well as the first 160 bits of any first randomNonce (PKCS#7)
extended attribute each replaced by the "filename safe" base64 SHA-384
hash of the unredacted TBScertificate, and shall embed SCTs in such
certificates just as for ServerAuth certificates. This crude one-off
form of redaction should allow full checking while not revealing spam
friendly e-mail addresses or physical locations of individual persons.
The same redaction shall be applied to other non-ServerAuth
certificates issued to named single natural persons whether in a
personal or professional capacity. The distinction between natural
persons (such as "J.Postel") and role names such as "IANA", shall be
based on the original validation data.

For certificates issued (NotBefore) without SCTs prior to
2017-07-01T00:00:00 UTC, the SHA-384 value shall be replaced by the
HMAC-SHA384 using SHA384(certificate signature) as key.

For example, a redacted TBScertificate could be for
CN=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
email=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
_@example.com,O=The Example Corporation,
street=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
L=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,ST=California,C=US
nonce=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
_\321\234\345\267 (192 bits nonce in cert, first 160 bits redacted).

Tech notes: SHA-384 was chosen because its size is a multiple of 3
bytes (4 base64 chars) and is at least 256 bits strong. 160 bits is
enough to stop dictionary attacks but not enough to generate SHA-384
birthday attacks. File name safe Base64 is from RFC3548 section 4.

Necessity: The Mozilla root program also cares about S/MIME
certificates, so those should get the same measures as WebPKI
certificates.

Proportionality: Same as for WebPKI. The quick-and-dirty redaction
process proposed is intended to prevent spamming and/or revelation of
(sometimes legally, sometimes only morally) protected personal
information that is likely to lead to risk of bodily harm to persons
with personal enemies (such as violent ex-spouses or political
extremists). In rare cases the revelation of the ST field may also
pose such risk (e.g. if the redacted information is identical to
otherwise known information about friends or relatives), it should be
considered during discussions if that should be redacted too

5. All stated requirements shall also apply to SubCA certificates other
than the specially blessed "Managed CA" SubCAs. These shall never be
redacted. As a special exception, the root programs may unanimously on
a one-by-one bases authorize the signing of additional Managed SubCAs
and/or new infrastructure cross certificates, subject to full
validation and signing ceremonies. The root programs will authorize
enough new infrastructure cross signatures if and when they include the
roots of the new infrastructure.

Necessity: This is to protect the community in case of further
misissuance of SubCAs by Symantec employees during the transition
period. Specifically, it distrusts SubCAs signed after the deadline.

Proportionality: This is a natural consequence of the overall plan,
and simply formalizes what is otherwise implied, namely that Symantec
doesn't issue new certs from the old infrastructure except as strictly
necessary.

6. All stated requirements except premature expiry and the prohibition
against later issuance shall apply to delegated OCSP signing, CRL
signing and other such revocation/validation related signatures made
by the existing Symantec CAs and SubCAs, but after the first deadline
(ultimo August), such shall only be used for the continued provision of
revocation information, and shall have corresponding EKUs. This
corresponds to standard rules for dead CA certs, but adds CT logging of
any delegated revocation signing certificates. These shall never be
redacted.

Necessity: Allowing the revocation infrastructure in present and
future forms (e.g. if there is a new revocation protocol introduced) to
continue is necessary to protect relying parties during and after the
transition.

Proportionality: This restates an existing BR contingency requirement
and explicitly permits Symantec to comply with it by excluding it from
the catch all clauses elsewhere.

7. All stated requirements except the premature expiry shall apply to
time stamping signatures and certificates for timestamps certifying a
time prior to the first deadline. On or before the first deadline,
operation of the Symantec timestamping URLs shall be delegated to one
or more of the Managed SubCA operators under specially designated
timestamping Managed SubCA certificate chains. If Symantec has a log
of all timestamps in any period before that, it shall publish an
SHA-512 Merkle hash tree over all the DER embeddable timestamps (either
the RFC3161 TimeStampToken or the Microsoft protocol response, either
being an PKCS#7 signedData) of such signatures (not the original hashes
and messages being timestamped). For Mozilla Corporation, the
continued public trust in Symantec timestamp signatures affects the
validity of code signatures on most previous Mozilla product releases
(such as Firefox installation packages), although Mozilla products
themselves don't currently trust any time stamping signatures.

Necessity: Timestamp signatures and their issuing CA chains are
unique in their need to remain valid very long (decades) after they
were made. The Merkle tree (if Symantec has the data, as they
certainly will for June, July, August 2017), provides a way to validate
(via a CT-like lookup) timestamp signatures whose algorithm or issuing
key has been subsequently compromised, as is almost the case with the
SHA-1 timestamp signatures still required for a number of uses. A
number of software signing procedures, including the one used in 2016
by Mozilla, also seem to lack vendor agility, thus causing them to
erroneously use Symantec timestamp servers even with 3rd party certs.

Proportionality: This is the same as the general requirements, but
modified to retain the long lifetime of time stamp signatures. The
Merkle tree serves to further lessen the damage at small cost to all
parties (including Symantec). By revealing only a strong hash of the
full PKCS#7 structure (which includes a signature blob), no information
is leaked about the time stamped objects, as required by RFC3161.

8. As Mozilla products don't currently trust any code or object signing
certificates, Mozilla places no requirements on those, but observes
that other root stores may have such requirements. Ditto for any other
certificate types not mentioned.

Necessity: Since this is no measure, it is the smallest possible
action.

Proportionality: This is the lightest possible touch.

9. Symantec shall be allowed and obliged to continue operation of the
special "managed signing" services for which it has in the past been
granted a technically enforced monopoly by various platform vendors,
but may delegate this ability to one or more of the vendor independent
Managed SubCA operators if legally and technically possible. This is
for the good of the community (in particular the relying parties using
affected platforms), as I don't think it affects any Mozilla products
(I don't think Fennec was ever released for those platforms).
Google may provide requirements for the handling of Google Play
private keys managed by Symantec on behalf of content vendors.

Necessity: End users of certain systems (such as Windows Mobile) are
prevented from installing any software not signed by a special Symantec
online procedure. Symantec may have similar relationships with other
platforms, or may be the custodian of signing keys for legacy systems
where the prior CA operator function relied on Symantec validations and
has since been shut down. This is one of the specific situations where
Symantec is too big to fail.
For the Google Play private key hosting ("managed signing"), Symantec
has put itself in contractual relationships requiring it to provide this
service on an ongoing basis. (Note to those unfamiliar: Each
Google Play content creator signs content with one or more self-signed
long term (25+ years) certificates, and Google products enforces that
content (including app) updates must be signed with the same such
certificate as version 1 of each piece of content. Actual identity
validation occurs when version 1 is accepted into the Google Play
store. Based on the technology used for its monopoly managed signing
services, Symantec convinced a number of content creators that it could
protect their private keys better than they could).

Proportionality: This requires Symantec to continue to serve
communities for which it has acquired an actual monopoly. Symantec
already charges for these services, thus the economic burden on Symantec
is limited to the fact that fixed costs can no longer be shared with the
CA activities that have been handed to Managed SubCAs.
Symantec is not prohibitied from reasonable price hikes on these
services, thus further lessening their burden. Eventually, these
services will need to be reinstantiated in the new infrastucture once
it is ready.
For the Google Play case, Symantec created these situations
themselves.



10. Symantec shall be allowed for marketing purposes, but not in legal
documents, to pretend to be the vendor behind the Managed SubCA
issuances, and may collect a profit or loss on the fees for each
certificate request. However Symantec may not pretend to, nor actually
obtain, any ownership, authority or affiliation of the Managed SubCA
operators, nor vice versa. I believe Symantec is very capable of
formulating effective marketing materials etc. that complies with this.
This permission is at the grace of the root stores and may be revoked
if further Symantec misbehavior occurs after 2017-05-20 at 00:00 PDT,
especially but not only if Symantec fails to file a Mozilla bug
admitting the incident before the latter of the independent reporting
of the incident or 48 hours after said incident. Mozilla will
independently timestamp such reports using its existing mechanisms and
share such timestamps and reports with Google and other cooperating
root programs.


Necessity: This is not necessary, but provides Symantec with
something to eat during the transition while providing the root stores
with a sanction short of distrust for minor infractions during the
transition.
The statement of clear deadlines for self-reporting issues is due to
the lateness of recent Symantec reports and responses.

Proportionality: This is mostly what would be implied by the plan,
except that some marketing shenanigans are tolerated. The Mozilla
timestamping is imagined to simply be the time stamps and sequential
numbers that Mozilla already assigns to all bug reports. The 48 hours
allowed post-incident even if someone else is quick to report the
incident is intended to just give Symantec Management time enough to
literally actually wake up, go to work, notice the misbehavior or other
incident and then quickly issue a report. The exact number 48 would be
negotiable during the 3 way negotiations.

[Rob Stradling]

On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:
<snip>

Hi Kathleen. I'm not quite sure how to interpret this part...

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this.

Are you saying that Symantec would be a Delegated Third Party that can
perform all of the validation and can trigger certificate issuance, but
that it would actually be a third-party CA that handles the new Symantec
PKI and issues certs (when triggered to do so by Symantec)?

Or, are you saying that Symantec would be permitted to operate their new
PKI in-house from day 1?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Kurt Roeckx]

On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via dev-security-policy wrote:
>
> Gerv, thank you for all the effort you have been putting into this investigation into Symantec's mis-issuances, and in identifying the best way to move forward with the primary goal being to help keep end-users safe.
>
> I fully support requiring Symantec to set up a new PKI on new infrastructure, and to transition to it in phases, in order to minimize the impact and reduce
> the risk for end-users.
>
> I think the general direction is correct, but I think there are a few details to be ironed out, such as:
>
> - What validity periods should be allowed for SSL certs being issued in the old PKI (until the new PKI is ready)? I prefer that this be on the order of 13 months, and not on the order of 3 years, so that we can hope to distrust the old PKI as soon as possible. I prefer to not have to wait 3 years to stop trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued this year.

So I think we have a few categories of certificates:
- Those issued in the past, which can still be valid for up to 3
years. I'm not sure when the last 5 year certificates are
supposed to expire, or if they all expired, but I don't think
those take long to expire.
- Those that still get issued before they move to some new PKI.

If you want to distrust their existing roots before those
certificates expire, this will most likely results in at least
some people having problems. And that it would be up to Symantec
to make sure those people get new certificates and started using
them.

>From the mail about Chrome's plan, I understand that Chrome's plan
is to only allow certificates from the old PKI if they qualify for
their CT requirements. They plan to only allow certificates issued
after 2016-06-01 because that's the date when they required CT
from Symantec. It seems that Symantec can still issue new certificates
using the old PKI up to 2017-08-08 that are still valid for 3
years.

I'm a little concerned that Firefox and Chrome will have different
certificates they don't trust, and would hope that you can come to
some agreement about when which one would get distrusted.

> - Perhaps the new PKI should only be cross-signed by a particular intermediate cert of a particular root cert, so that we can begin to distrust the rest of the old PKI as soon as possible.

I'm not really sure what you're saying here. If the new PKI is
signed by an other CA, does it matter if it's signed by their
root CA or some (dedicated) intermediate? I don't see how that
relates to distruting the old PKI.

I have a problem with one CA signing an other unrelated CA. I
would prefer that we have a policy that forbids that, and that the
CA should make sure it's own root gets added to the root store.
The only reason I can see for cross signing is for people that still
using an old root store.

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this.

So they should just create new root CAs and ask them to be
included in the root store?


Kurt

[Michael Casadevall]

Comments inline.

On 05/19/2017 05:10 PM, Jakob Bohm wrote:
> Suggested trivial changes relative to the proposal for Mozilla use:
>

> 3. All non-expired Symantec issued certificates of any kind (including
> SubCAs and revoked certificates) shall be CT logged as modified by #4
> below. All Symantec referenced OCSP responders shall return SCTs for
> all such certificates, if possible even for revoked certificates. This
> also applies to expired certificates that were intended for use with
> validity extending timestamping, such as the code signing certificate
> issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f
> c9 71 67 0e 73 e3 69 c7 91. Independent parties or root stores may at
> their option use this data to generate public trust whitelists.
>
> Necessity: Whitelists in various forms based on such CT log entries,
> as well as the SCTs in OCSP responses can provide an alternative for
> relying parties checking current certificates even if the cleanup at
> Symantec reveals a catastrophic breach during the past 20+ years.
>
> Proportionality: This should be relatively easy for the legitimate
> certificates issued by Symantec, since the underlying data is still
> used for OCSP response generation.
>

Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to
be created at the time of issuance. Not sure if there's a way to
backdate this requirement. If this is only intended for the new roots
then just a point of clarification.

> 4. All stated requirements shall also apply to S/MIME certificates.

<snip out a technical solution to S/MIME redaction>

I *really* like this since it solves the problem of S/MIME + CT, but I
think this has to get codified into a specification. My second thought
here though is that there's no way to independently check if the CT logs
correspond to reality unless you have the public certificate since the
hashed fields would cause the signature to break.

I'd love to see this go somewhere but probably needs a fair bit of
thought and possible use of a different CT log vs. the primarily webPKI
ones.

>
> 5. All stated requirements shall also apply to SubCA certificates other
> than the specially blessed "Managed CA" SubCAs. These shall never be
> redacted. As a special exception, the root programs may unanimously on
> a one-by-one bases authorize the signing of additional Managed SubCAs
> and/or new infrastructure cross certificates, subject to full
> validation and signing ceremonies. The root programs will authorize
> enough new infrastructure cross signatures if and when they include the
> roots of the new infrastructure.
>

Believe this was already covered by the PKI concerns that Symantec would
not be allowed to use third-party validation. Not sure if we can
realistically do a technical measure here since if we put a NotBefore
check in NSS, we have no easy way to change it in the future if it
becomes necessary for a one-off.

>
> 6. All stated requirements except premature expiry and the prohibition
> against later issuance shall apply to delegated OCSP signing, CRL
> signing and other such revocation/validation related signatures made
> by the existing Symantec CAs and SubCAs, but after the first deadline
> (ultimo August), such shall only be used for the continued provision of
> revocation information, and shall have corresponding EKUs. This
> corresponds to standard rules for dead CA certs, but adds CT logging of
> any delegated revocation signing certificates. These shall never be
> redacted.
>

I think this can be more easily put as "intermediate certificates
restricted via EKU for use for OCSP/CRL shall always be trusted for
purposes of maintain infrastructure". I don't think there's much risk of
a subCA that's limited to these roles to general webPKI unless such a
certificate was used to misissue a CRL that blacklisted all of
Symantec's certificates (which wouldn't be our problem per say).

>
> 7. All stated requirements except the premature expiry shall apply to
> time stamping signatures and certificates for timestamps

> 8. As Mozilla products don't currently trust any code or object
> signing certificates

> 9. Symantec shall be allowed and obliged to continue operation of the
> special "managed signing" services

Can't help but feel that this is out of scope; Mozilla only cares about
emailProtection and serverAuth EKU bits. A few CAs still have code
signing bits in NSS due to historic reasons but Mozilla isn't a
code-signing root store.

What other root stores (especially those not related to WebPKI) is not
our business.

> 10. Symantec shall be allowed for marketing purposes ...

I'm hesitant on this one because this requirement seems overly broad and
out of line with current practice. Going to leave it for other people to
poke at.

Michael

[Michael Casadevall]

On 05/19/2017 05:43 PM, Kurt Roeckx wrote:
> So I think we have a few categories of certificates:
> - Those issued in the past, which can still be valid for up to 3
> years. I'm not sure when the last 5 year certificates are
> supposed to expire, or if they all expired, but I don't think
> those take long to expire.
> - Those that still get issued before they move to some new PKI.
>
> If you want to distrust their existing roots before those
> certificates expire, this will most likely results in at least
> some people having problems. And that it would be up to Symantec
> to make sure those people get new certificates and started using
> them.
>

When it boils down to that, I'm OK with the existing certs being allowed
to age out (perhaps capped to 39 months total if there are any five year
certificates still floating around) as long as new issuances are stopped
from the old roots within a reasonable time frame.

That being said, new issuances from the existing PKI should be capped on
expiration.

>>From the mail about Chrome's plan, I understand that Chrome's plan
> is to only allow certificates from the old PKI if they qualify for
> their CT requirements. They plan to only allow certificates issued
> after 2016-06-01 because that's the date when they required CT
> from Symantec. It seems that Symantec can still issue new certificates
> using the old PKI up to 2017-08-08 that are still valid for 3
> years.
>
> I'm a little concerned that Firefox and Chrome will have different
> certificates they don't trust, and would hope that you can come to
> some agreement about when which one would get distrusted.
>

This was likely unavoidable due to the simple fact that the
Google-Symantec discussions happened behind closed doors. Unless we can
influence Google's final policy, then this is likely going to be the
case no matter what.

> I have a problem with one CA signing an other unrelated CA. I
> would prefer that we have a policy that forbids that, and that the
> CA should make sure it's own root gets added to the root store.
> The only reason I can see for cross signing is for people that still
> using an old root store.
>

++ here

>> - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this.
>

The current proposal is more complicated than that since it talks about
reusing part of the original validations and OIDs to control the max
length of the certificate. I rather dislike that since its both complex,
and introduces the trust issues from the old hierarchy into the new one
which moots the point of spinning up a new root in the first place.

> So they should just create new root CAs and ask them to be
> included in the root store?
>

Honestly, we got into this mess in the first place due to third-party
signers. I don't think the right solution to stopping a gas fire is to
throw more gas on it.
Michael

[Nick Lamb]

On Saturday, 20 May 2017 15:49:44 UTC+1, Michael Casadevall wrote:
> Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to
> be created at the time of issuance. Not sure if there's a way to
> backdate this requirement. If this is only intended for the new roots
> then just a point of clarification.

Issuance of the certificate? No, I don't think so. For a typical big CA which is creating its OCSP responses in advance and then serving the canned responses via a CDN, obviously the SCTs need to be known when that's done, but that doesn't seem too hard to arrange.

[userwithuid]

To me, the most noticable difference between how Google and Mozilla can take action is with regards to exisiting certs. As proposed, Google has a really neat timeline to get rid of Symantec's questionable legacy stuff quickly and effectively. (Legacy stuff which we - and arguably Symantec themselves judging from their responses on here so far - still don't have a complete picture of).

Come 2018-01-18 (8 months from now), Google could comfortably say it _actually_ only trusts (relatively) new Symantec certs - thanks to the 2016-06 CT requirement. No more undisclosed old subCAs that are technically capable of issuing trusted certs, no more reliance on notBefore which could technically be faked; if they choose to do so, Google can enable unconditional technical enforcement of CT for all things Symantec and everyone who is interested can use the logs to get a complete picture of what will actually be trusted in Chrome 65.

Mozilla doesn't have this (yet). Google's first proposal would have been great because if all certs have to be reissued within a year anyway to be trusted by Chrome (~ half of the browser market), Mozilla could have at least implemented a simple notBefore check to latch on to that legacy purge. With the new proposal, the "minimal disruption" solution for Firefox will require keeping the legacy stuff around for another 3.5-4 years and better solutions will now be a lot harder to sell without the leverage provided by Google. Quite unfortunate development.

This has the potential to end up mirroring the WoSign response, where Mozilla and Apple sanction new certs via notBefore and then... wait - worst case up to 3.5 years - while Google acts and effectively gets rid of the legacy in < 1 year using technical restrictions.*

Now I can't think of any fix other than "copy Chrome -> enforce CT" or "prematurely distrust older certs anyway -> make everyone hate or ditch Mozilla", maybe someone else knows a way. As it stands, I suspect that in all likelihood Chromium will again have the better code solution over Firefox, which is kinda meh, but whatever. :-)



* FTR: Google fucked up majorly by not communicating their plan and deadlines for WoSign clearly. Critical info on future distrust steps was only vaguely hinted at in the single proper announcement made on this. Still, it's awesome to see the agreed upon policy change (= distrust current WoSign, have them start fresh with new roots) implemented within a reasonable timeframe.

[Michael Casadevall]

On 05/21/2017 02:37 PM, userwithuid wrote:
> To me, the most noticable difference between how Google and Mozilla can take action is with regards to exisiting certs. As proposed, Google has a really neat timeline to get rid of Symantec's questionable legacy stuff quickly and effectively. (Legacy stuff which we - and arguably Symantec themselves judging from their responses on here so far - still don't have a complete picture of).
>

There's also a fair number of points dealing with who can sign and for
what while Symantec spins up the new roots (which the Google proposal
says a trusted third party CA signed by Symantec").

I'm against this point specifically because third-party CA operations is
how we got into this mess. I rather cap new certificate length from the
existing roots as both a way to light a fire under Symantec and to avoid
the same old mistakes.
Michael

[userwithuid]

On Sunday, May 21, 2017 at 11:31:54 PM UTC, Michael Casadevall wrote:
> There's also a fair number of points dealing with who can sign and for
> what while Symantec spins up the new roots (which the Google proposal
> says a trusted third party CA signed by Symantec").
>
> I'm against this point specifically because third-party CA operations is
> how we got into this mess.

I agree with your general concern, but the OP states:

"These sub-CAs must be operated by a non-affiliated organization that operates roots currently trusted in the Android and Chrome OS trust stores that have been trusted for a period of at least two years."

This to me sounds very similar in theory to Certum/Asseco doing OV for WoSign, which on this list has been considered OK. Personally, I'd rather not have any of this CA mixing, 3rd-party delegating, cross-signing of whole trees, root-buying etc. but all this stuff seems to be an integral part of current industry practice.+

I say in theory because Symantec's "good arguments" (aka monies) have the potential to make the selected CA their bi...dding doer by means of contract in reality. What else is new though? I'm positive Symantec would have always found some business arrangement with another CA for their customers that want > 9 months cert lifetime and/or EV under Google's first proposal, so we would have gotten some "Managed CA" one way or the other. Worst case it would have been mixed in with other certs, not having a dedicated subCA or other marker. Now it's explicit, separate and even has some additional rules.

NSS* already trusts that other CA to do proper validation right now, and they might just be smart enough to realize that they will be watched way more closely when Symantec starts using them to not do anything totally stupid. I honestly think that this "Managed CA" will get more practical oversight both by auditors and by the community than most of the roots in NSS.



+ Appreciation footnote for the DTP discussion @ cabf and the GlobalSign->Google root transfer discussion on here
* Android trust store seems to be a subset of NSS'

[Gervase Markham]

On 19/05/17 21:04, Kathleen Wilson wrote:
> - What validity periods should be allowed for SSL certs being issued
> in the old PKI (until the new PKI is ready)?

Symantec is required only to be issuing in the new PKI by 2017-08-08 -
in around ten weeks time. In the mean time, there is no restriction
beyond the normal one on the length they can issue. This makes sense,
because if certs issued yesterday will expire 39 months from yesterday,
then certs issued in 10 weeks will only expire 10 weeks after that - not
much difference.

> I prefer that this be on
> the order of 13 months, and not on the order of 3 years, so that we
> can hope to distrust the old PKI as soon as possible. I prefer to not
> have to wait 3 years to stop trusting the old PKI for SSL, because a
> bunch of 3-year SSL certs get issued this year.

If we want to distrust the old PKI as soon as possible, then instead of
trying to limit issuance period now, we should simply set a date after
which we are doing this, and require Symantec to have moved all of their
customers across to the new PKI by that time.

Google are doing a phased distrust of old certs, but they have not set a
date in their plan for total distrust of the old PKI. We should ask them
what their plans are for that.

> - I'm not sold on the idea of requiring Symantec to use third-party
> CAs to perform validation/issuance on Symantec's behalf. The most
> serious concerns that I have with Symantec's old PKI is with their
> third-party subCAs and third-party RAs. I don't have particular
> concern about Symantec doing the validation/issuance in-house. So, I
> think it would be better/safer for Symantec to staff up to do the
> validation/re-validation in-house rather than using third parties. If
> the concern is about regaining trust, then add auditing to this.

Of course, if we don't require something but Google do (or vice versa)
then Symantec will need to do it anyway. But I will investigate in
discussions whether some scheme like this might be acceptable to both
the other two sides and might lead to a quicker migration timetable to
the new PKI.

Gerv

[Gervase Markham]

On 19/05/17 22:10, Jakob Bohm wrote:
> Necessity: Whitelists in various forms based on such CT log entries,
> as well as the SCTs in OCSP responses can provide an alternative for
> relying parties checking current certificates even if the cleanup at
> Symantec reveals a catastrophic breach during the past 20+ years.

Do you know anyone who would consider shipping such a whitelist? I
suspect size considerations would rule it out, given that this was the
concern raised for much smaller lists of certs. And if we did want to
ship it, we would just ask Symantec for a list of certificates - no need
for all this.

> Necessity: The Mozilla root program also cares about S/MIME
> certificates, so those should get the same measures as WebPKI
> certificates.

That sems a very weak justification for requiring something which would
be a ton of work and require us to invent a new CT redaction scheme for
S/MIME certs. None of the issues raised related to S/MIME.

> Proportionality: This is a natural consequence of the overall plan,
> and simply formalizes what is otherwise implied, namely that Symantec
> doesn't issue new certs from the old infrastructure except as strictly
> necessary.

That is not an implied outcome. Symantec can issue as many certs as they
want from the old infrastructure; it's just that browsers will no longer
trust them. I'm totally certain Symantec's existing PKI will keep
running for many years to come to support non-publicly-trusted use cases.

> 7. All stated requirements except the premature expiry shall apply to
> time stamping signatures and certificates for timestamps certifying a
> time prior to the first deadline.

Mozilla does not care about such certificates.

> 9. Symantec shall be allowed and obliged to continue operation of the
> special "managed signing" services for which it has in the past been
> granted a technically enforced monopoly by various platform vendors,

Mozilla does not care about such certificates.

Gerv

[Gervase Markham]

On 19/05/17 22:16, Rob Stradling wrote:> Are you saying that Symantec

would be a Delegated Third Party that can
> perform all of the validation and can trigger certificate issuance, but
> that it would actually be a third-party CA that handles the new Symantec
> PKI and issues certs (when triggered to do so by Symantec)?

I believe that's her suggestion, yes.

The volume of validations Symantec needs to do is a concern; I believe
this is why Google are permitting a phased introduction to the
requirement that the validations be redone. One way to avoid this
problem is, well, not requiring that the validations be redone, or
allowing Symantec personnel to continue doing them.

> Or, are you saying that Symantec would be permitted to operate their new
> PKI in-house from day 1?

This would mean allowing Symantec to run the new PKI from some form of
their old infrastructure. That seems to defeat a lot of the point of
requiring a new one.

Gerv

[Gervase Markham]

On 21/05/17 19:37, userwithuid wrote:
> With the new proposal, the "minimal disruption" solution for Firefox
> will require keeping the legacy stuff around for another 3.5-4 years
> and better solutions will now be a lot harder to sell without the
> leverage provided by Google.

Why so? In eight months' time, if Chrome is no longer trusting certs
issued before 2016-06-01, why would it be a problem for Firefox to stop
trusting them shortly thereafter?

Gerv

[Kurt Roeckx]

On Mon, May 22, 2017 at 05:33:26PM +0100, Gervase Markham via dev-security-policy wrote:
> Google are doing a phased distrust of old certs, but they have not set a
> date in their plan for total distrust of the old PKI. We should ask them
> what their plans are for that.

My understanding is that Google will rely on CT for it and
don't need to distrust anything. Either it's in CT and we
can check what they did, or it's not and it's not trusted.


Kurt

[Jakob Bohm]

Comments inline

The ideas here are:

1. To establish a temporary ad-hoc solution that can be handled by
existing CT log software logging the redacted precertificates. This is
so solving the Symantec problem won't have to wait for general
standardization, which has stalled on this issue. A standardized form
would be more compact and involve at least one "CT Extension" attribute.

2. By definition, any redaction would prevent CT log watchers from
checking if the unredacted cert signatures are valid. This is
unavoidable, but not a problem for any known good uses of CT logs.

3. The design is intended to ensure that any process seeing an actual
cert can check it against SCTs obtained in any way (e.g. present in
cert, present in OCSP response, direct CT query, ...) by forming at most
one candidate redacted form, using mostly code likely to be already
present in such processes.

4. The design is intended to prevent recovering redacted data by
dictionary attacks (= guess and check). This means that for existing
certs without a strong nonce attribute, logging the signature over the
unredacted final cert is also out of the question, such old certs need
to be logged as precerts only.

>>
>> 5. All stated requirements shall also apply to SubCA certificates other
>> than the specially blessed "Managed CA" SubCAs. These shall never be
>> redacted. As a special exception, the root programs may unanimously on
>> a one-by-one bases authorize the signing of additional Managed SubCAs
>> and/or new infrastructure cross certificates, subject to full
>> validation and signing ceremonies. The root programs will authorize
>> enough new infrastructure cross signatures if and when they include the
>> roots of the new infrastructure.
>>
>
> Believe this was already covered by the PKI concerns that Symantec would
> not be allowed to use third-party validation. Not sure if we can
> realistically do a technical measure here since if we put a NotBefore
> check in NSS, we have no easy way to change it in the future if it
> becomes necessary for a one-off.
>

This would be an administrative requirement not checked by client
software directly, except that client software can check for the
presence of SCTs in any new SubCAs, and root programs can check the logs
for non-approved SubCA issuance.

>>
>> 6. All stated requirements except premature expiry and the prohibition
>> against later issuance shall apply to delegated OCSP signing, CRL
>> signing and other such revocation/validation related signatures made
>> by the existing Symantec CAs and SubCAs, but after the first deadline
>> (ultimo August), such shall only be used for the continued provision of
>> revocation information, and shall have corresponding EKUs. This
>> corresponds to standard rules for dead CA certs, but adds CT logging of
>> any delegated revocation signing certificates. These shall never be
>> redacted.
>>
>
> I think this can be more easily put as "intermediate certificates
> restricted via EKU for use for OCSP/CRL shall always be trusted for
> purposes of maintain infrastructure". I don't think there's much risk of
> a subCA that's limited to these roles to general webPKI unless such a
> certificate was used to misissue a CRL that blacklisted all of
> Symantec's certificates (which wouldn't be our problem per say).
>

As stated in the part you elided, this #6 is merely to say this in a
formal way, and emphasize that OCSP delegation certs etc. need to be CT
logged too.

The item is phrased like the others for overall consistency.

>>
>> 7. All stated requirements except the premature expiry shall apply to
>> time stamping signatures and certificates for timestamps
>> 8. As Mozilla products don't currently trust any code or object
>> signing certificates
>> 9. Symantec shall be allowed and obliged to continue operation of the
>> special "managed signing" services
>
> Can't help but feel that this is out of scope; Mozilla only cares about
> emailProtection and serverAuth EKU bits. A few CAs still have code
> signing bits in NSS due to historic reasons but Mozilla isn't a
> code-signing root store.
>
> What other root stores (especially those not related to WebPKI) is not
> our business.
>

The rationales given for each clearly deal with this:

#7 is about what Mozilla Corporation may benefit from even though it
does not narrowly involve the Mozilla root program.

#8 is exactly saying that this is out of scope for Mozilla.

#9 clearly says it is about a benefit to the community, but not to
Mozilla specifically (unless I am wrong about Fennec (Firefox Mobile)
being available on affected platforms).

>> 10. Symantec shall be allowed for marketing purposes ...
>
> I'm hesitant on this one because this requirement seems overly broad and
> out of line with current practice. Going to leave it for other people to
> poke at.
>

This is specifically about ensuring their continued cooperation during
the multi-year transition. The plan as it is takes away most of the
other ways in which the root programs (including the Mozilla root
program) can pressure Symantec to behave themselves.

[Jakob Bohm]

On 22/05/2017 18:33, Gervase Markham wrote:
> On 19/05/17 21:04, Kathleen Wilson wrote:
>> - What validity periods should be allowed for SSL certs being issued
>> in the old PKI (until the new PKI is ready)?
>
> Symantec is required only to be issuing in the new PKI by 2017-08-08 -
> in around ten weeks time. In the mean time, there is no restriction
> beyond the normal one on the length they can issue. This makes sense,
> because if certs issued yesterday will expire 39 months from yesterday,
> then certs issued in 10 weeks will only expire 10 weeks after that - not
> much difference.
>

Note that the plan (at least as I read it), involves two major phases:

1. The transition "Managed SubCAs", these will continue to chain to the
old PKI during the transition, but it is possible for clients and root
programs to limit the trust to those specific "Managed SubCAs" instead
of the sprawling old certificate trees. This does not involve CT
checking in clients, just trust decisions.

2. The truly "new infrastructure", built properly to modern standards
will not be ready until some time has passed, and will be a new root
program applicant with new root CA certs. Once those roots become
accepted by multiple root programs (at least Google and Mozilla), the
new root CAs can begin to issue via "new infrastructure" SubCAs that
are signed by both "new root CAs" (for updated clients) and old root
CAs (for old clients).

>> I prefer that this be on
>> the order of 13 months, and not on the order of 3 years, so that we
>> can hope to distrust the old PKI as soon as possible. I prefer to not
>> have to wait 3 years to stop trusting the old PKI for SSL, because a
>> bunch of 3-year SSL certs get issued this year.
>
> If we want to distrust the old PKI as soon as possible, then instead of
> trying to limit issuance period now, we should simply set a date after
> which we are doing this, and require Symantec to have moved all of their
> customers across to the new PKI by that time.
>
> Google are doing a phased distrust of old certs, but they have not set a
> date in their plan for total distrust of the old PKI. We should ask them
> what their plans are for that.
>

I understood certs issued by the old systems (except the listed Managed
SubCAs) will be trusted only if issued and CT logged between 2016-06-01
and 2017-08-08, and will be subject to the BR lifetime requirements for
such certs. Thus no such certs will remain trusted after approximately
2020-08-08 plus the slack in the BRs.

Clients without SCT checking (NSS ?) cannot check the presence of SCTs,
but can still check the limited range of notBefore dates.

>> - I'm not sold on the idea of requiring Symantec to use third-party
>> CAs to perform validation/issuance on Symantec's behalf. The most
>> serious concerns that I have with Symantec's old PKI is with their
>> third-party subCAs and third-party RAs. I don't have particular
>> concern about Symantec doing the validation/issuance in-house. So, I
>> think it would be better/safer for Symantec to staff up to do the
>> validation/re-validation in-house rather than using third parties. If
>> the concern is about regaining trust, then add auditing to this.
>
> Of course, if we don't require something but Google do (or vice versa)
> then Symantec will need to do it anyway. But I will investigate in
> discussions whether some scheme like this might be acceptable to both
> the other two sides and might lead to a quicker migration timetable to
> the new PKI.
>
> Gerv
>

[userwithuid]

A)

It wouldn't. Specifically, for all certs under current Symantec roots, to sync with Google we can check:

1. If the chain contains a whitelisted intermediate (= "Managed CA"), don't impose further notBefore restrictions
2. For all other intermediates, only trust certs with notBefore between 2016-06-01 and 2017-08-08

This is a whole lot better than no restrictions and should definitely be done. (Also, Jakob explained this above as well, I'm just repeating it).

My point was about the fringe parts of Symantec's current PKI. In 8 months, Chrome will _actually_ eliminate all of those using both CT-enforcement and notBefore => the "old" PKI is now WYSIWYG and quite fresh from their point of view. No more unknowns or waiting for Symantec to draw their map and discover SSP2 while forgetting SSP3. :-P

For Firefox, this doesn't hold true. Not all certs under Symantec roots issued since 2016-06-01 are or need to be CT-enabled, so that date doesn't really align with better issuance practices for everything Mozilla actually trusts.

At the end of the day it's gonna be fine of course: Most of the legacy will also be disabled in practice with the notBefore restrictions in Firefox. And anyway: What good is a cert if it isn't trusted by half of all web users? We can ride that Chrome market share wave. Still, Google's solution w.r.t. to the old PKI is just technically superior.



B)

Anyway, I don't want to derail the discussion and get back to what to do with the intermediate PKI ("Managed CA" under old roots) and new PKI (new roots, 2018?), that is also very important.

One suggestion on that: Let's define the date on which we remove the old roots from NSS and disallow the use of any "Managed CA" via policy so that the intermediate PKI can't tranform into a de-facto long-term PKI. This is meant to force Symantec to focus their efforts on their own new roots. I don't think they should have that intermediate PKI as a comfy fallback when things with the new roots don't turn out that well or get delayed (they seem to have a tendency for delaying things...).

One such date would be 2021-06-01, after the last 39 months cert issued by the Managed CA on 2018-02-28 expires. That allows the Managed CA to operate unrestricted (only BR-compliant) until 2019-02-28 at least, then enter a sunset period with shorter lifetimes. Lots of time to get the new roots fully operational.

We could shave off up to 7 months on both dates (purge and sunset) if we don't allow the Managed CA to issue 39mo certs in the first place, only 27. Mozilla's first proposal was 13 months for new certs, so 27 - which will become mandatory soon anyway - sounds quite reasonable to me.

[Ryan Sleevi]

On Sat, May 20, 2017 at 11:12 AM, Michael Casadevall via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On 05/19/2017 05:43 PM, Kurt Roeckx wrote:

> >>From the mail about Chrome's plan, I understand that Chrome's plan
> > is to only allow certificates from the old PKI if they qualify for
> > their CT requirements. They plan to only allow certificates issued
> > after 2016-06-01 because that's the date when they required CT
> > from Symantec. It seems that Symantec can still issue new certificates
> > using the old PKI up to 2017-08-08 that are still valid for 3
> > years.
> >
> > I'm a little concerned that Firefox and Chrome will have different
> > certificates they don't trust, and would hope that you can come to
> > some agreement about when which one would get distrusted.
> >
>

> This was likely unavoidable due to the simple fact that the
> Google-Symantec discussions happened behind closed doors. Unless we can
> influence Google's final policy, then this is likely going to be the
> case no matter what.
>

(Wearing a Google Hat)
As noted in the blink-dev posting,

“While the plan is not final, we believe it is converging on one that

strikes a good balance of addressing security risk and mitigating
interruption. We still welcome any feedback about it, as prior feedback has

been valuable in helping shape this plan.”

>> - I'm not sold on the idea of requiring Symantec to use third-party CAs
> to perform validation/issuance on Symantec's behalf. The most serious
> concerns that I have with Symantec's old PKI is with their third-party
> subCAs and third-party RAs. I don't have particular concern about Symantec
> doing the validation/issuance in-house. So, I think it would be
> better/safer for Symantec to staff up to do the validation/re-validation
> in-house rather than using third parties. If the concern is about regaining
> trust, then add auditing to this.
> >
>

> The current proposal is more complicated than that since it talks about
> reusing part of the original validations and OIDs to control the max
> length of the certificate. I rather dislike that since its both complex,
> and introduces the trust issues from the old hierarchy into the new one
> which moots the point of spinning up a new root in the first place.
>

The Chrome plan outlined attempts to minimize disruption to site operators,
as disruptions to sites are reflected as disproportionate disruptions to
users, by virtue of seeing security errors. Both in discussions with
Symantec and within the broadly understood operation of the Web PKI, many
sites - particularly those that are engaged in automated issuance through
the use of APIs - routinely replace certificates. Introducing a blocking
step - the reverification of information - into obtaining a certificate,
can end up creating situations where certificates are expired and not
revalidated in a timely fashion.



While the long-term solution for this is to require the use of standardized
issuance APIs - such as the work on ACME being developed within the IETF
<https://datatracker.ietf.org/wg/acme/charter/> - and to reduce both the
lifetime of certificates and the reuse of validation responses - so that
the difficulty in revalidating is greatly reduced, by virtue of it becoming
routine and thus automated as well - these solutions are not yet widely
deployed by site operators, and thus not reliable for these immediate
purposes.



The solution outlined attempts to find a technical solution to allow a
variety of relying party applications to make trust decisions appropriate
for their community, while also providing sufficient technical guidance,
both as a matter of policy and expressed in the certificate, that can allow
more robust controls.



For example, relying party applications could choose to fully trust the
existing certificate set. They could distrust those prior to 2016-06-01,
and simply implicitly rely on herd immunity by virtue of Chrome’s support
for CT. They could fully implement CT, and have more robust protections,
such as the ability to reject redacted certificates or require the use of
trusted CT logs (and not merely the presence of an SCT extension).



Similarly, they can simply accept all certificates from the new hierarchy.
They could accept certificates only up to the timelines proposed. They
could implement different timelines entirely - although, I note, if
products feel that need, we, the Chrome team, would be interested in
understanding this as part of our overall effort to find an interoperable
solution, if possible. For that matter, clients could decide that the risk
from previous domain validations and previous organizational validations
may be so large that they only accept certificates that have been fully
revalidated - and the proposal provides a means and method for them to
determine such certificates, in a way compatible with RFC 5280.

> So they should just create new root CAs and ask them to be
> > included in the root store?
> >
>

> Honestly, we got into this mess in the first place due to third-party
> signers. I don't think the right solution to stopping a gas fire is to
> throw more gas on it.
>

The existing situation emerged from a complex number of factors, most
notably, inappropriate oversight of a sprawling, complex infrastructure
that had been in existence for decades. While it may seem undesirable that
the solution for this involves introducing a new PKI, the proposal, as
written, provides a transitional path to resolve the systematic issues with
the infrastructure, policies, and issuance, on meaningful timescales, and
in a way that minimizes disruption to users.

[Ryan Sleevi]

On Mon, May 22, 2017 at 12:33 PM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 19/05/17 21:04, Kathleen Wilson wrote:

> > - I'm not sold on the idea of requiring Symantec to use third-party
> > CAs to perform validation/issuance on Symantec's behalf. The most
> > serious concerns that I have with Symantec's old PKI is with their
> > third-party subCAs and third-party RAs. I don't have particular
> > concern about Symantec doing the validation/issuance in-house. So, I
> > think it would be better/safer for Symantec to staff up to do the
> > validation/re-validation in-house rather than using third parties. If
> > the concern is about regaining trust, then add auditing to this.
>

> Of course, if we don't require something but Google do (or vice versa)
> then Symantec will need to do it anyway. But I will investigate in
> discussions whether some scheme like this might be acceptable to both
> the other two sides and might lead to a quicker migration timetable to
> the new PKI.
>

(Wearing a Google Hat)

This requirement is born directly out of Issues C, D and N, and indirectly
out of Issues B, F, L, P, Q, T, V, W, Y.

The appropriateness of validation controls depends on the policies and
procedures that are established by Management, the day to day execution of
this by Validation Specialists, and the technical controls and designs to
detect or prevent any human error from being introduced.

Understandably and obviously, domain validation represents a critical
function, and the evidence and disclosures have made it clear that domain
validation was not consistently followed, either from the system design or
by validation specialists.

Similarly, the indirect issues highlight issues with overall process design
and documentation - an issue explicitly called out in the remediation of
Issue D and subsequently Issue W - that raise concerns about the validation
processes.

To allow validation to continue as a Delegated Third Party, which is what
would be necessary to permit what was described, is to bring in all of the
issues raised with aspects of both oversight (now with respect to the
Managed CA overseeing Symantec’s validation operations) and execution, both
of which would both create opportunity for new issues and incompletely
resolve existing issues.

Given the nature of the integration here, we do not believe it would
reasonably speed up any migration to allow what is proposed. That is, the
initial efforts with respect to establishing the Managed CA infrastructure
are orthogonal to the question of validation, and reflect API integrations
and business contracting. This is why, as part of our proposal, issuance
can proceed without forcing an immediate transition to revalidation.

However, by requiring revalidation, phased in over time, there is an
objective and quantifiable level of security improvement, reflected through
the independence of the operation and the robust technical controls - that
provides a clear and objective manner of re-establishing trust. These are
incredibly important concerns for Google, as we seek to ensure that
solutions to restore trust in CAs are appropriate for the nature of the
concerns and reusable, in the event another CA should have issue. This
represents the only way we have identified to reliably provide assurance
that the validation issues have been concretely resolved, and that the
policies fully reflect the Baseline Requirements both now and going
forward, and with robust controls to ensure that.

We are, of course, interested in if there are technical means to achieve
this same result - that validations are sufficiently documented in
policies, consistently executed on both a technical and procedural level,
and appropriately overseen through both technical and procedural controls -
in a manner that is both objective and transparent, thus reusable, and
which suitably meets the needs of the broader ecosystem. We welcome any
ideas that can establish this without relying solely on audits, which are
demonstrably insufficient, as evidenced by the issues with respect to
Delegated Third Parties, their operation, and their overall supervision.

[Peter Bowen]

On Mon, May 22, 2017 at 9:33 AM, Gervase Markham via

dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 19/05/17 21:04, Kathleen Wilson wrote:

>> - What validity periods should be allowed for SSL certs being issued
>> in the old PKI (until the new PKI is ready)?
>

> Symantec is required only to be issuing in the new PKI by 2017-08-08 -
> in around ten weeks time. In the mean time, there is no restriction
> beyond the normal one on the length they can issue. This makes sense,
> because if certs issued yesterday will expire 39 months from yesterday,
> then certs issued in 10 weeks will only expire 10 weeks after that - not
> much difference.

Can you clarify the meaning of "new PKI"? I can see two reasonable
interpretations:

1) The systems and processes used to issue end-entity certificates
(server authentication and email protection) must be distinct from the
existing systems. This implies that a new set of subordinate CAs
under the existing Symantec-owned roots would meet the requirements.
These new subordinate CAs could be owned and operated by either
Symantec or owned and operated by a third party who has their own
WebTrust audit.

2) The new PKI includes both new offline CAs that meet the
requirements to be Root CAs and new subordinate CAs that issue
end-entity certificates. the The new root CAs could be cross-signed by
existing CAs (regardless of owner), but the new subordinate CAs must
not be directly signed by any Symantec-owned root CA that currently
exists.

Can you also clarify the expectations with regards to the existing
roots? You say "only to be issuing in the new PKI". Does Mozilla
intend to require that all CAs that chain to a specific set of roots
cease issuing all server authentication and email protection after a
certain date, unless they are also under one of the "new" roots? If
so, will issuance be allowed from CAs that chain to the "old" roots
once certain actions take place (e.g. removed from the trust stores in
all supported versions of Mozilla products)?

>> - I'm not sold on the idea of requiring Symantec to use third-party
>> CAs to perform validation/issuance on Symantec's behalf. The most
>> serious concerns that I have with Symantec's old PKI is with their
>> third-party subCAs and third-party RAs. I don't have particular
>> concern about Symantec doing the validation/issuance in-house. So, I
>> think it would be better/safer for Symantec to staff up to do the
>> validation/re-validation in-house rather than using third parties. If
>> the concern is about regaining trust, then add auditing to this.
>

> Of course, if we don't require something but Google do (or vice versa)
> then Symantec will need to do it anyway. But I will investigate in
> discussions whether some scheme like this might be acceptable to both
> the other two sides and might lead to a quicker migration timetable to
> the new PKI.

Google has proposed adding some indication to certificates of whether
the information validation was performed by Symantec or another party.
If Mozilla does not require a third-party to perform validation, would
it make sense to have a concept of validations performed by the "new"
RA and validations performed by the "old" RA or validations performed
in the scope of Symantec audits versus validations performed in the
scope of another audit?

Thanks,
Peter

[Gervase Markham]

On 24/05/17 16:33, Peter Bowen wrote:
> Can you clarify the meaning of "new PKI"? I can see two reasonable
> interpretations:

....

> 2) The new PKI includes both new offline CAs that meet the
> requirements to be Root CAs and new subordinate CAs that issue
> end-entity certificates. the The new root CAs could be cross-signed by
> existing CAs (regardless of owner), but the new subordinate CAs must
> not be directly signed by any Symantec-owned root CA that currently
> exists.

I was imagining a variant of this, where the subordinate CAs were
cross-signed, but basically this one. I'd assumed that the new PKI
proposed would mean new roots. It certainly means new long-term trust
anchors, so I would expect Symantec to construct it such that they have
new roots (perhaps four - one ECC, one RSA for both EV and non-EV?) and
use them to issue new intermediates, which are then given to the 3rd
party CA to manage. And there's some cross-signing somewhere to make it
all work in old browsers.

> Can you also clarify the expectations with regards to the existing
> roots? You say "only to be issuing in the new PKI". Does Mozilla
> intend to require that all CAs that chain to a specific set of roots
> cease issuing all server authentication and email protection after a
> certain date, unless they are also under one of the "new" roots? If
> so, will issuance be allowed from CAs that chain to the "old" roots
> once certain actions take place (e.g. removed from the trust stores in
> all supported versions of Mozilla products)?

I think that once the new intermediates are set up, we would change
Firefox to:

* Directly trust certs which chain through the new intermediates, i.e.
without relying on the legacy path;
* Only trust certs which are old-PKI-only with a notBefore before a
certain date.

So Symantec would not be prevented from issuing new certs in their old
PKI, but Firefox would no longer trust them.

Eventually, we would like to distrust the old PKI altogether; the
timeline for that is currently the subject of an outstanding question to
Google as to whether they have plans for that.

> Google has proposed adding some indication to certificates of whether
> the information validation was performed by Symantec or another party.
> If Mozilla does not require a third-party to perform validation, would
> it make sense to have a concept of validations performed by the "new"
> RA and validations performed by the "old" RA or validations performed
> in the scope of Symantec audits versus validations performed in the
> scope of another audit?

What decisions might we make on the basis of such a distinction?

Gerv

[Gervase Markham]

Here's my roundup of things I think we should require of Symantec.

* Mozilla would wish, after 2017-08-08, to alter Firefox such that it
trusts certificates issued in the "new PKI" directly by embedding a set
of certs or trust anchors which are part of that PKI, and can therefore
distrust any new cert which is issued by the old PKI on a "notBefore"
basis. Symantec need to arrange their new PKI and provide us with
sufficient information to be able to do that. Google also require this
AFAICS, so it should not be difficult.

* Mozilla would wish, at some point in the future sooner than November
2020 (39 months after August 2017), to be certain that we are fully
distrusting the old Symantec PKI. As things currently stand technically,
this would mean removing the roots, and so Symantec would have to move
their customers to the new PKI at a rate faster than natural certificate
expiry. Rather than arbitrarily set a date here, we are willing to
discuss what date might be reasonable with Symantec, but would expect it
to be some time in 2018.

* If any additional audit is performed by Symantec, including but not
limited to one that "that includes a description of the auditor’s tests
of controls and results", then the intended users of the audit report
must also include persons who assist in decisions related to the trusted
status of Certification Authorities within Mozilla products. For any
audit to unusually detailed criteria, it is permitted to place this
information behind a login (or require it to be so placed) as long as
Mozilla is allowed to give access to any member of our community that we
wish.[0]

None of these things, as far as I can see, would need Google to change
their plan.

Have I missed anything? If we want to request changes in the Google plan
to accommodate something we want to do, I think we may need to do so
pretty soon.

Gerv


[0] AIUI, this is a technical thing relating to auditor standards and
the intended users of a report. The aim here is to make it effectively
public without making it actually public, to work around some issues in
this space. Don't worry about it.

[Gervase Markham]

Hi Steve,

I'm writing to you in your role as the Primary Point of Contact for
Symantec with regard to the Mozilla Root Program. I am writing with a
list of Mozilla-specific additions to the consensus remediation proposal
for Symantec, as documented by Google.

We note that you have raised a number of objections and queries with
regard to the consensus proposal. As you know, we are considering our
responses to those. We reserve the right to make additional requests of
Symantec in relation to any changes which might be made to that
proposal, or for other reasons.

However, we have formulated an initial list of Mozilla-specific addenda
to the consensus proposal and feel now is a good time to pass them on to
Symantec for your official consideration and comment. We would prefer
comments in mozilla.dev.security.policy (to which this notice has been
CCed), and in any event by close of business on Monday 12th June.

1) Mozilla would wish, after the 2017-08-08 date as documented in the
consensus proposal, to alter Firefox such that it trusts certificates

issued in the "new PKI" directly by embedding a set of certs or trust
anchors which are part of that PKI, and can therefore distrust any new

cert which is issued by the old PKI on a "notBefore" basis. We therefore
require that Symantec arrange their new PKI and provide us with
sufficient information in good time to be able to do that.

2) Mozilla would wish, at some point in the future sooner than November
2020 (39 months after 2017-08-08, the date when Symantec need to be
doing new issuance from the new PKI), to be certain that we are fully
distrusting the old PKI. As things currently stand technically,
distrusting the old PKI would mean removing the roots, and so Symantec

would have to move their customers to the new PKI at a rate faster than
natural certificate expiry. Rather than arbitrarily set a date here, we
are willing to discuss what date might be reasonable with Symantec, but
would expect it to be some time in 2018.

As you know, Firefox currently does not act upon embedded CT
information, and so CT-based mechanisms are not a suitable basis for us
to determine trust upon. Were that to change, we may be able to consider
a continued trust of CT-logged certs, but would still want to dis-trust
non-CT-logged certs sooner than November 2020.

3) If any additional audit is performed by Symantec, including but not

limited to one that "that includes a description of the auditor’s tests
of controls and results", then the intended users of the audit report
must also include persons who assist in decisions related to the trusted
status of Certification Authorities within Mozilla products. For any
audit to unusually detailed criteria, it is permitted to place this
information behind a login (or require it to be so placed) as long as
Mozilla is allowed to give access to any member of our community that we
wish.

We look forward to hearing Symantec's response to these requirements.

With best wishes,

Gerv

[Jakob Bohm]

Hi Gervase,

there seems to be a slight inconsistency between the terminology in the
plan posted at

https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

And the official letter quoted below. I have added potential
clarifications to fix this, please indicate, for the benefit of the
community and Symantec if those clarifications are correct interpretations.

On 07/06/2017 20:51, Gervase Markham wrote:
> Hi Steve,
>
> I'm writing to you in your role as the Primary Point of Contact for
> Symantec with regard to the Mozilla Root Program. I am writing with a
> list of Mozilla-specific additions to the consensus remediation proposal
> for Symantec, as documented by Google.
>
> We note that you have raised a number of objections and queries with
> regard to the consensus proposal. As you know, we are considering our
> responses to those. We reserve the right to make additional requests of
> Symantec in relation to any changes which might be made to that
> proposal, or for other reasons.
>
> However, we have formulated an initial list of Mozilla-specific addenda
> to the consensus proposal and feel now is a good time to pass them on to
> Symantec for your official consideration and comment. We would prefer
> comments in mozilla.dev.security.policy (to which this notice has been
> CCed), and in any event by close of business on Monday 12th June.
>
> 1) Mozilla would wish, after the 2017-08-08 date as documented in the
> consensus proposal, to alter Firefox such that it trusts certificates
> issued in the "new PKI" directly by embedding a set of certs or trust
> anchors which are part of that PKI, and can therefore distrust any new
> cert which is issued by the old PKI on a "notBefore" basis. We therefore
> require that Symantec arrange their new PKI and provide us with
> sufficient information in good time to be able to do that.
>

Potential clarification: By "New PKI", Mozilla apparently refers to the
"Managed CAs", "Transition to a New Symantec PKI" and related parts of
the plan, not to the "new roots" for the "modernized platform" / "new
infrastructure".

> 2) Mozilla would wish, at some point in the future sooner than November
> 2020 (39 months after 2017-08-08, the date when Symantec need to be
> doing new issuance from the new PKI), to be certain that we are fully
> distrusting the old PKI. As things currently stand technically,
> distrusting the old PKI would mean removing the roots, and so Symantec
> would have to move their customers to the new PKI at a rate faster than
> natural certificate expiry. Rather than arbitrarily set a date here, we
> are willing to discuss what date might be reasonable with Symantec, but
> would expect it to be some time in 2018.
>
> As you know, Firefox currently does not act upon embedded CT
> information, and so CT-based mechanisms are not a suitable basis for us
> to determine trust upon. Were that to change, we may be able to consider
> a continued trust of CT-logged certs, but would still want to dis-trust
> non-CT-logged certs sooner than November 2020.
>
> 3) If any additional audit is performed by Symantec, including but not
> limited to one that "that includes a description of the auditor’s tests
> of controls and results", then the intended users of the audit report
> must also include persons who assist in decisions related to the trusted
> status of Certification Authorities within Mozilla products. For any
> audit to unusually detailed criteria, it is permitted to place this
> information behind a login (or require it to be so placed) as long as
> Mozilla is allowed to give access to any member of our community that we
> wish.
>

Potential clarification: Mozilla's #3 requirement applies to both the
"new PKI" and the "new roots" for the "new infrastructure".

> We look forward to hearing Symantec's response to these requirements.
>
> With best wishes,
>
> Gerv
>

[Gervase Markham]

On 07/06/17 22:30, Jakob Bohm wrote:
> Potential clarification: By "New PKI", Mozilla apparently refers to the
> "Managed CAs", "Transition to a New Symantec PKI" and related parts of
> the plan, not to the "new roots" for the "modernized platform" / "new
> infrastructure".

I expect those things to be interlinked; by "New PKI" I was referring to
them both.

Symantec has not yet stated how they plan to structure their new
arrangements, but I would expect that the intermediate certs run by the
managed CAs would in some way become part of Symantec's new PKI,
operated by them, once it was up and running. Ryan laid out a way
Symantec could structure this on blink-dev, I believe, but the final
structure is up to them.

> Potential clarification: Mozilla's #3 requirement applies to both the
> "new PKI" and the "new roots" for the "new infrastructure".

Yes, I suppose so, although I would expect such an extra-detailed audit
to be done on the new infrastructure rather than on the Managed CA
infrastructure which is owned by another CA.

Gerv

[Jakob Bohm]

On 08/06/2017 11:09, Gervase Markham wrote:
> On 07/06/17 22:30, Jakob Bohm wrote:
>> Potential clarification: By "New PKI", Mozilla apparently refers to the
>> "Managed CAs", "Transition to a New Symantec PKI" and related parts of
>> the plan, not to the "new roots" for the "modernized platform" / "new
>> infrastructure".
>
> I expect those things to be interlinked; by "New PKI" I was referring to
> them both.
>
> Symantec has not yet stated how they plan to structure their new
> arrangements, but I would expect that the intermediate certs run by the
> managed CAs would in some way become part of Symantec's new PKI,
> operated by them, once it was up and running. Ryan laid out a way
> Symantec could structure this on blink-dev, I believe, but the final
> structure is up to them.
>

As the linked proposal was worded (I am not on Blink mailing lists), it
seemed obvious that the original timeline was:

August 2017: All new certs issued by Managed SubCAs that chain to the
old Symantec roots. Private keys for these SubCAs reside an the third
party CAs in secure hardware which will presumable prevent sharing them
with Symantec.

Much later: The new infrastructure passes all readiness audits.

Then: A signing ceremony creates the new roots and their first set of
SubCAs. Cross signatures are created from the old roots to the new
roots. Maybe/Maybe not cross signatures are also created from the new
roots to the managed SubCAs.

Next: Symantec reapplies for inclusion with the new roots.

Later: Once the new roots are generally accepted, Symantec can
actually issue from the new SubCAs.

Long term: CRL and OCSP management for the managed SubCAs remain with
the third party CAs. This continues until the managed SubCAs expire or
are revoked.

[Peter Bowen]

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> As the linked proposal was worded (I am not on Blink mailing lists), it
> seemed obvious that the original timeline was:
>

> Later: Once the new roots are generally accepted, Symantec can actually
> issue from the new SubCAs.
>
> Long term: CRL and OCSP management for the managed SubCAs remain with the
> third party CAs. This continues until the managed SubCAs expire or are
> revoked.

I don't see this last part in the proposal. Instead the proposal
appears to specifically contemplate the SubCAs being transferred to
Symantec once the new roots are accepted in the required trust stores.

Additionally, there is no policy, as far as I know, that governs
transfer of non-Root CAs. This is possibly a gap, but an existing
one.

Thanks,
Peter

[Jakob Bohm]

On 08/06/2017 18:52, Peter Bowen wrote:
> On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>>
>> As the linked proposal was worded (I am not on Blink mailing lists), it
>> seemed obvious that the original timeline was:
>>
>> Later: Once the new roots are generally accepted, Symantec can actually
>> issue from the new SubCAs.
>>
>> Long term: CRL and OCSP management for the managed SubCAs remain with the
>> third party CAs. This continues until the managed SubCAs expire or are
>> revoked.
>
> I don't see this last part in the proposal. Instead the proposal
> appears to specifically contemplate the SubCAs being transferred to
> Symantec once the new roots are accepted in the required trust stores.
>

That last part was derived purely from the logistical difficulty of
moving private keys compared to just keeping CRL and OCSP running in an
infrastructure that would keep running anyway (for the hosting CAs own
CA certificates).

[Steve Medin]

Symantec supports creation of a new PKI. Limiting Firefox trust of new certificates to those issued off of the new PKI is a practical path forward, due to Firefox’s contained scope and auto-update capabilities.

The same does not hold true for the removal of current PKI roots from NSS and the entirety of NSS dependents.

We understand the cutoff date to mean that any end entity cert issued after that date from the current PKI would not be trusted, but this date would have no effect on the trust of existing current PKI certs, their issuers, or their roots. Mozilla has not yet chosen the notBefore milestone date, and we interpret your proposal as intent to set a date and announce that date with enough advance notice to support public notice to affected parties. To that end, based on our research, we believe the 2017-08-08 date is not achievable given the magnitude of the transition that would need to occur and we propose that Mozilla not conclude on final dates for Symantec certificates at this time.

In response to the Google proposal, Symantec is currently evaluating a third party “SubCA” approach, which requires substantial operational changes. We have conducted outreach to candidate partners (SubCAs) to understand the potential constraints, timelines and the integration work that might be needed. We have also formalized and issued an RFP with specific questions around timing, logistics and dependencies. We expect to have the required feedback to inform a project plan by the end of June, at which time we will come back to Mozilla and the community regarding suggested dates that are both aggressive and achievable under this approach, by Symantec and the SubCA(s).

> 2) Mozilla would wish, at some point in the future sooner than November
> 2020 (39 months after 2017-08-08, the date when Symantec need to be
> doing new issuance from the new PKI), to be certain that we are fully
> distrusting the old PKI. As things currently stand technically, distrusting the
> old PKI would mean removing the roots, and so Symantec would have to
> move their customers to the new PKI at a rate faster than natural certificate
> expiry. Rather than arbitrarily set a date here, we are willing to discuss what
> date might be reasonable with Symantec, but would expect it to be some
> time in 2018.
>
> As you know, Firefox currently does not act upon embedded CT
> information, and so CT-based mechanisms are not a suitable basis for us to
> determine trust upon. Were that to change, we may be able to consider a
> continued trust of CT-logged certs, but would still want to dis-trust non-CT-
> logged certs sooner than November 2020.
>

We think it is critically important to distinguish potential removal of support for current roots in Firefox versus across NSS. Limiting Firefox trust to a subset of roots while leaving NSS unchanged would avoid unintentionally damaging ecosystems that are not browser-based but rely on NSS-based roots such as code signing, closed ecosystems, libraries, etc.

As one example, we note that libraries that rely on NSS in non-browser based applications, many of which are not easily updated, may have unintended negative impact in automobiles, television sets, routers, printers, mobile phones, tablets, set top boxes, and media players.

We believe that the concern is in regards to the integrity of certificates issued from subCAs that were authenticated by both Symantec’s team and those of our former SSL/TLS RAs, given concerns related to the practices of the RAs. With the exception of Issue D in 2015, the validation practices of Symantec’s authentication team are not in question. Mozilla has publicly supported our in-house team’s work as “better/safer” than requiring third parties to perform validation. That same Symantec authentication team has now completed a full revalidation of CrossCert authenticated certificates and a 100% review of those from all other SSL/TLS RAs. We are finalizing our disclosure about that revalidation/review effort that proved on average 96% of RA-issued certificates fully satisfied our criteria that, in many aspects, exceed the Baseline Requirements. Any exception certificates have been revoked. And of the 4% remaining, the revocations we conducted were largely necessitated by errors in spelling, translation, location tier, or abbreviation. As a result, we don’t see a reason for shorter trust of existing certificates from these subCAs.

Should Mozilla see a need to establish a cutoff in Firefox for trust of certificates from our current PKI, we recommend harmonizing that approach with other browsers – and specifically anchor that trust around whether or not the certificates have been logged to CT and include SCTs. We began logging certificates to CT starting in January 2015 and moved to 100% logging in June 2016. We assert that the certificates we have authenticated and issued have been issued correctly. While we understand that Firefox does not act upon CT information, CT, independent of any one browser, still provides domain owners the ability to determine if certificates issued to their domains were authorized. CT monitors are easily available (and some free). The ability for members of the Mozilla community to leverage CT has required no work by Mozilla (e.g. to support SCT extensions or any of CT’s technical implementation), but nevertheless has allowed issues to be found and the associated risk to be managed. We see this as an appropriate risk-based approach to transitioning from the current PKI within Firefox to a new one while limiting unnecessary customer disruption.

> 3) If any additional audit is performed by Symantec, including but not
> limited to one that "that includes a description of the auditor’s tests of
> controls and results", then the intended users of the audit report must also
> include persons who assist in decisions related to the trusted status of
> Certification Authorities within Mozilla products. For any audit to unusually
> detailed criteria, it is permitted to place this information behind a login (or
> require it to be so placed) as long as Mozilla is allowed to give access to any
> member of our community that we wish.
>

We share our audit reports today and auditors are required to include in those reports any material findings. We responded to Google that we would be willing to share other reports of a sensitive nature under non-disclosure. Enabling any member of the Mozilla community, which we interpret as potentially an unlimited number of persons, to access detailed audit reports is difficult to allow without a clear understanding and agreement on the level of detail we would share or redact.

Our assumptions about the information you ask us to disclose may be different from yours. Therefore, we would like to better understand the scope of the information you want to see to determine whether exposure of that information is a manageable risk and acceptable to the audit firms. WebTrust auditors are not required to disclose their test of controls and our experience has been that auditors in general will not consent to publicly disclose additional information regarding their audit engagement beyond what is established by the audit standards they follow. We welcome more input from the community including auditors as well.

[Nick Lamb]

On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin wrote:
> We think it is critically important to distinguish potential removal of support for current roots in Firefox versus across NSS. Limiting Firefox trust to a subset of roots while leaving NSS unchanged would avoid unintentionally damaging ecosystems that are not browser-based but rely on NSS-based roots such as code signing, closed ecosystems, libraries, etc.

Abusing NSS to support code signing or "closed ecosystems" would be an error regardless of what happens to Symantec, it makes no real sense for us to prioritize supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS certdata other than Firefox, they've _already_ represented very strongly that what they want is for this data to follow Mozilla's trust decisions more closely not less.

I have no doubt that Symantec believes it could make more money if archaic Symantec-controlled CA roots remain in NSS certdata forever but it doesn't serve Mozilla's wider purpose to allow that, nor does it serve the purpose of the non-Mozilla people on m.d.s.policy.

Further the use of NSS certdata in libraries is absolutely key to a secure Web PKI. I spent a good portion of last week and will probably spend more time yet chasing problems with such libraries. It may well suit Symantec to be able to tell their customers "We can issue you anything [for a fee] and it'll be trusted by libraries" knowing you've advocated for this, but it hurts the Relying Parties because it exposes them to unlimited risk which will be disclaimed later as "not affecting Firefox".

[Jakob Bohm]

On 12/06/2017 22:12, Nick Lamb wrote:
> On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin wrote:
>> We think it is critically important to distinguish potential removal of support for current roots in Firefox versus across NSS. Limiting Firefox trust to a subset of roots while leaving NSS unchanged would avoid unintentionally damaging ecosystems that are not browser-based but rely on NSS-based roots such as code signing, closed ecosystems, libraries, etc.
>
> Abusing NSS to support code signing or "closed ecosystems" would be an error regardless of what happens to Symantec, it makes no real sense for us to prioritize supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS certdata other than Firefox, they've _already_ represented very strongly that what they want is for this data to follow Mozilla's trust decisions more closely not less.
>

I believe you are exaggerating in that assertion.

NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a defunct code
signing trust bit in the NSS root store).

I also believe that the current checking of "AMO" signatures is still
done by NSS, but not using the public PKI.

This makes it completely reasonable for other users of the NSS libraries
to still use it for code signing, provided that the "code signing" trust
bits in the NSS root store are replaced with an independent list,
possibly based on the CCADB.

It also makes it likely that systems with long development / update
cycles have not yet deployed their own replacement for the code signing
trust bits in the NSS root store, even if they have a semi-automated
system importing changes to the NSS root store. That would of cause be
a mistake on their part, but a very likely mistake.

[Ryan Sleevi]

On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> NSS until fairly recently was in fact used for code signing of Firefox
> extensions using the public PKI (this is why there is a defunct code
> signing trust bit in the NSS root store).
>

This is not an accurate representation on why there is a code signing trust
bit in the NSS root store.

> I also believe that the current checking of "AMO" signatures is still
> done by NSS, but not using the public PKI.
>

If you mean with respect to code, sure, but that is a generic signature
checking.

> This makes it completely reasonable for other users of the NSS libraries
> to still use it for code signing, provided that the "code signing" trust
> bits in the NSS root store are replaced with an independent list,
> possibly based on the CCADB.
>

This is not correct. The NSS team has made it clear the future of this code
with respect to its suitability as a generic "code signing" functionality -
that is, that it is not.

> It also makes it likely that systems with long development / update
> cycles have not yet deployed their own replacement for the code signing
> trust bits in the NSS root store, even if they have a semi-automated
> system importing changes to the NSS root store. That would of cause be
> a mistake on their part, but a very likely mistake.

This was always a mistake, not a recent one. But a misuse of the API does
not make a valid use case.

[Jakob Bohm]

On 20/06/2017 09:05, Ryan Sleevi wrote:
> On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> NSS until fairly recently was in fact used for code signing of Firefox
>> extensions using the public PKI (this is why there is a defunct code
>> signing trust bit in the NSS root store).
>>
>
> This is not an accurate representation on why there is a code signing trust
> bit in the NSS root store.
>

Then what is an accurate representation?

I am of cause aware that before the xpi format was even invented,
Netscape, Mozilla and Sun/Oracle used the NSS key store and possibly the
NSS code to validate signatures on Java applets. But I am unsure if and
when they stopped doing that.

>
>> I also believe that the current checking of "AMO" signatures is still
>> done by NSS, but not using the public PKI.
>>
>
> If you mean with respect to code, sure, but that is a generic signature
> checking.
>

Really? I would have thought it was the same validation code previously
used for public PKI signatures on the same file types.

Anyway, it is most certainly checking signatures on code in a way
consistent with the general concept of "code signing" (the exact
placement and formatting of "code signing" signatures is extremely
vendor and file format dependent).

>
>> This makes it completely reasonable for other users of the NSS libraries
>> to still use it for code signing, provided that the "code signing" trust
>> bits in the NSS root store are replaced with an independent list,
>> possibly based on the CCADB.
>>
>
> This is not correct. The NSS team has made it clear the future of this code
> with respect to its suitability as a generic "code signing" functionality -
> that is, that it is not.
>

Pointer?

Was this communicated in a way visible to all NSS using software?

>
>> It also makes it likely that systems with long development / update
>> cycles have not yet deployed their own replacement for the code signing
>> trust bits in the NSS root store, even if they have a semi-automated
>> system importing changes to the NSS root store. That would of cause be
>> a mistake on their part, but a very likely mistake.
>
>
> This was always a mistake, not a recent one. But a misuse of the API does
> not make a valid use case.
>

How was it a mistake back when Mozilla was using NSS for "code signing"?
(Whenever that was).

P.S.

I am following the newsgroup, no need to CC me on replies.