On 06/06/2017 16:02, Gervase Markham wrote:
On 02/06/17 15:53, Gervase Markham wrote:
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
I'm slightly surprised to see no engagement here. Perhaps it would be
help to break it down. Symantec's specific requests for modification are
as follows (my interpretation):
Thanks for actually putting the information in the newsgroup, not in
linked documents. Makes responding much easier.
1) Scope of Distrust
Google proposal: existing CT-logged certificates issued after 1st June
2016 would continue to be trusted until expiry.
Symantec proposal: all CT-logged certificates should continue to be
trusted until expiry.
Rationale for change: if transparency is enough to engender trust, that
principle should be applied consistently. This also significantly
reduces the revalidation burden.
I think the period where trust is added because of CT logging doesn't
need to be limited.
There may be specific *other* dates before/after which Symantec
validation processes cannot be trusted, but a specific reason other than
availability of CT logs should be given for such dates.
2) Timeline
Google proposal: a set of dates by which certain milestones must be
achieved.
Symantec proposal: no specific alternative dates (more info by the end
of June), but the Google dates are too aggressive.
Rationale: need to establish business relationships; capacity issues at
Managed CAs; international requirements further complicate things; the
revalidation burden is very large; writing solid code takes time.
Given how long this has dragged out, 3rd party CA negotiations may need
a slight extension, but not forever. 3rd party CAs approached for this
job may negotiate harder due to the deadline imposed on Symantec, but
that's a consequence of Symantec's actions, which Symantec must simply
suffer. It should be possible for Symantec to negotiate with other 3rd
party CAs to get a better deal later in the transitional (outsourced)
period, which would imply Mozilla and Chrome accepting new "Managed
SubCAs" being stood up as a consequence.
3) SubCA Audit Type
Google proposal: SubCAs are audited with the standard audits.
Symantec proposal: treat SubCAs as Delegated Third Parties and so give
them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
Rationale: none given.
Full audit should be required.
4) Validation Task Ownership
Google proposal: Symantec and its affiliates must not participate in any
of the information verification roles permitted under the Baseline
Requirements. They may, however, collect and aggregate information.
Symantec proposal: Symantec currently uses a 2-step process - validation
and review. Symantec should be allowed to do the first, with the SubCA
doing the second (with 100% review, not samplingh).
Rationale: reducing the burden on the SubCA, reducing the time for them
to ramp up, and (presumably) to allow the Symantec personnel to continue
to have jobs.
If Symantec retains their ability to issue non-TLS certs in-house, the
excess validation team man-hours should be used to improve the
thoroughness of the validation of those other certificate types, in
preparation for using such better validation practices in the
post-transition new PKI. Other important uses for those excess
man-hours is security training, participating in design and beta-testing
the systems for the new PKI, and perhaps some paid vacations.
It would be bad long-term strategy for Symantec to fire specially
trained personnel that they will need again after rebuilding their
"factory". Paying people to just remain available during factory
downtime is a cost that any business risks, and Symantec will just have
to eat that cost.
5) Use of DTPs by SubCA
Google proposal: SubCAs may not use Delegated Third Parties in the
validation process for domain names or IP addresses.
Symantec proposal: SubCAs should be allowed to continue to use them in
situations where they already do.
Rationale: SubCAs should not be required to rejig their processes to
work with Symantec.
Maybe the 3rd party SubCAs should be allowed to still use RAs *only to
the extent* they do so for their own already included roots.
For example, they may use RAs to check local document types for OV and
EV certs, if they already do so.
They should not be allowed to use Symantec or any of the (former)
Symantec RAs as RAs for the "Managed SubCA" work.
They should be allowed to still use "Enterprise RAs" as defined in the
BRs.
6) SubCA Audit Timing
Google proposal: SubCAs are audited at 3 month intervals in the 1st
year, 6 months intervals in the 2nd year, and then yearly.
Symantec proposal: after the initial audit, only yearly audits should be
required.
Rationale: Because SubCAs are established CAs, once an audit has been
done to validate the transition, the subsequent audit schedule should be
the standard yearly one, not the high-frequency 3/6 month one proposed.
Sounds fair.
7) Detailed Audits
Google proposal: Symantec may be requested to provide "SOC2" (more
detailed) audits of their new infrastructure prior to it being ruled
acceptable for use.
Symantec proposal: such audits should be provided only under NDA.
Rationale: they include detailed information of a sensitive nature.
I don't see a problem in access to this being subject to a reasonable
NDA that allows Mozilla to show it to their choice of up to 50 external
experts (I don't expect to be one of those 50).
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
