Re: Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Peter Bowen via dev-security-policy]

On Mon, May 22, 2017 at 9:33 AM, Gervase Markham via
dev-security-policy  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Ryan Sleevi via dev-security-policy]

On Mon, May 22, 2017 at 12:33 PM, Gervase Markham via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Ryan Sleevi via dev-security-policy]

On Sat, May 20, 2017 at 11:12 AM, Michael Casadevall via
dev-security-policy  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
 - 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?
> >

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

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




Enjoy

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

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

Comments inline

On 20/05/2017 16:49, Michael Casadevall wrote:

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.




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.



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 

Re: Google Plan for Symantec posted

[Kurt Roeckx via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[userwithuid via dev-security-policy]

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'
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Nick Lamb via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

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.



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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Kurt Roeckx via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Rob Stradling via dev-security-policy]

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


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

On 19/05/2017 17:41, Gervase Markham wrote:

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 
Reply-To:   rsle...@chromium.org
To: blink-dev 
CC: Ryan Sleevi , awhal...@chromium.org

...



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

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Kathleen Wilson via dev-security-policy]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Google Plan for Symantec posted

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, May 19, 2017 11:42 AM
> To: mozilla-dev-security-pol...@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

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 
Reply-To:   rsle...@chromium.org
To: blink-dev 
CC: Ryan Sleevi , awhal...@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
.


When the original Intent to Deprecate was posted, I proposed
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


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