Google Trust Services roots

[Peter Bowen]

A couple of weeks ago, Google announced Google Trust Services
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html)
and also announced that they have acquired two roots that are in
Mozilla trust store.

As discussed in this group previously, Mozilla does not have a very
clear policy on root transfer, but does have a clear policy on audit
requirements and disclosure.  Based on the material published in the
blog and at the Google Trust Services website (https://pki.goog), I'm
not clear that the transfer and operation meets Mozilla's
requirements.

First, according to the GTS website, there is no audit using the
WebTrust Principles and Criteria for Certification Authorities –
Extended Validation SSL.  However the two roots in the Mozilla CA
program currently are EV enabled and at least one subordinate CA under
them is issuing EV certificates.

Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8
December 2016, Google Inc. operated these Roots according to Google
Inc.’s Certification Practice Statement."  The basic WebTrust for CA
and WebTrust BR audit reports for the period ending September 30, 2016
explicitly state they are for "subordinate CA under external Root CA"
and do not list the roots in the GTS CPS at all.

Third, the Google CPS says Google took control of these roots on
August 11, 2016.  The Mozilla CA policy explicitly says that a bug
report must be filed to request to be included in the Mozilla CA
program.  It was not until December 22, 2016 that Google requested
inclusion as a CA in Mozilla's CA program
(https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).  This does not
appear to align with Mozilla requirements for public disclosure.

Fourth, the audit reports linked in the bug explicitly set the scope
of "subordinate CA operated under external Root CA" and do not include
any indication of controls around the issuance of subordinate CA
certificates.  These audit reports do not have an appropriate scope
for a root CA.

I realize the discussion period for Google's inclusion request is
likely many months off, I believe that it is important to address
these issues soon, as they impact roots currently in the Mozilla CA
program.

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

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi]

On Sat, Feb 4, 2017 at 3:10 AM, Gervase Markham  wrote:

> On 31/01/17 04:51, Steve Medin wrote:
> > Our response to questions up to January 27, 2017 has been posted as an
> > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.
>
> Quoting that document:
>
> "Q: 4) In response to the previous incident, Symantec indicated it
> updated its internal policies and procedures for test certificates as
> used for commercial certificates. Further, it indicated that QA
> engineers and authentication personnel were trained on updated practices
> for test certificates. a) Did Symantec include Registration Authorities
> in the scope of that training?
>
> A: We did not train partners on an issue that pertained to a tool they
> could not access."
>
> -- That seems to miss the point of the question somewhat. The problem in
> the previous incident was poor practices surrounding the issuance of
> test certificates, not simply the tool that was used to issue them.
>
> 1) Did Symantec do any additional training for RAs regarding the
> issuance of test certificates after the last incident? If not, why not?
> Did Symantec believe that it was very unlikely for RA personnel to make
> the same mistakes or have the same misunderstandings of what was
> appropriate as Symantec's personnel?
>
> You also write: "Category C concluded prior to that last audit’s review
> period."


Steve,

To echo Gerv's remarks, the statement Symantec issued for the previous
misissuance [1] stated:
"Symantec has updated its internal policies and procedures to strongly
reinforce that all test certificates must follow the same fulsome
authentication procedures as commercial certificates."

Section 9.8 of the Baseline Requirements, v1.4.2 states
"For delegated tasks, the CA and any Delegated Third Party MAY allocate
liability between themselves contractually
as they determine, but the CA SHALL remain fully responsible for the
performance of all parties in accordance with
these Requirements, as if the tasks had not been delegated. "

1) Does Symantec believe that the original statement is sufficiently clear
that it was limited solely to Symantec's role in validating, and did not
extend to that of Delegated Third Parties?
2) Did Symantec management believe it was not necessary to notify and
inform its Delegated Third Parties about the need and significance to
conform to Symantec's CP and CPS, and of the necessity of ensuring that all
issued certificates - regardless of mechanism - must follow the same
fulsome authentication procedures?

Similarly, the statement Symantec issued for the previous misissuance [1]
stated:
"Symantec updated its internal policies, procedures, and trainings to
clarify the April 2014 change in the Baseline Requirements that removed
authorization to issue certificates to unregistered domains."

Your most recent response, [2], notes that:
"RAs are required to follow the same policies as set forth in Symantec’s CP
and CPS documents."

Regarding Certisign:
3) The most recent version of Certisign's CP/CPS that I'm able to publicly
confirm is http://vtn.certisign.com.br/repositorio/politicas/DPC_
da_Certisign.pdf , which is dated 2012. Is this the correct CP/CPS?
4) Can Symantec confirm that this is the CP/CPS that was audited?
5) Does Symantec believe that this CP/CPS is consistent with Symantec's
update CP and CPS documents updated in response to the previous misissuance?
6) Does Symantec believe that the audit letter, indicated in [2], which
clearly indicates that the effective criteria were based on "SSL Baseline
Requirements Audit Criteria, Version 1.1", available at [3], represents a
sufficient demonstration of conformance to Symantec's CP/CPS?
7) Does Symantec believe that the audit letter, indicated in [2], conducted
by Ernst and Young Brazil, conforms with the professional obligations with
respect to WebTrust licensing, and Symantec's obligation to ensure said
compliance as part of its Delegated Third Party conformance to the Baseline
Requirements' audit standards? Specifically, the requirement to use
"WebTrust for CA - SSL Baseline with Network Security 2.0" for all audits
whose periods begin after 1-Jul-14, which EY Brazil demonstrably did not
follow?

Regarding Certsuperior:
Symantec has indicated that the 2016 audit of Certsuperior was qualified,
as demonstrated in [4]. During Symantec's previous misissuance event,
Symantec noted that:
"We have also enhanced our compliance function by consolidating all
compliance activities into a single group reporting directly to the head of
our Website Security business unit. This change was made in January 2016;
this new compliance structure includes enhanced identification, tracking,
prioritization and resolution of compliance-related updates, which will
help ensure that CA/Browser Forum rule changes are effectively implemented."

8) Was Symantec's compliance group involved in reviewing the qualified
audit report findings?
9) Did Symantec's management 

Re: The prevalence of HTTPS interception

[Eric Mill]

The concluding discussion has a lot of great pointers to future work and
things the security community needs to work out. This part is relevant to
this community (and my favorite part of the paper):

Many HTTPS security features expect connections to be end-to-end by mixing
the HTTP and TLS layers, and by implementing HTTPS features in browser code
rather than in TLS libraries. For example, to overcome weaknesses in
existing revocation protocols, Firefox ships with OneCRL [43] and Chrome,
CRLSets [24]. Both of these solutions increase browser security in the
typical end-to-end case. However, these solutions provide no protection in
the presence of a TLS proxy and because the solution is not part of the TLS
protocol itself, TLS libraries do not implement these safe revocation
checks. In a second example, HPKP directives are passed over HTTP rather
than during the TLS handshake. Browsers cannot perform HPKP validation for
proxied connections because they do not have access the destination
certificate and proxies do not perform this validation in practice.

While it is possible for proxies to perform this additional verification,
they are not doing so, and in many cases vendors are struggling to
correctly deploy existing TLS libraries, let alone implement additional
security features. Given this evidence, our community needs to decide what
roles should be carried out by the browser versus TLS implementation. If we
expect browsers to perform this additional verification, proxies need a
mechanism to pass connection details (i.e., server certificate and
cryptographic parameters) to the browser. If we expect proxies to perform
this validation, we need to standardize these validation steps in TLS and
implement them in standard libraries. Unfortunately the current situation,
in which we ignore proxy behavior, results in the worst case scenario where
neither party is performing strict validation.


On Wed, Feb 8, 2017 at 10:26 AM, Gervase Markham  wrote:

> Of interest to those involved in security policy: a paper by a group,
> including Mozillians, about the high levels of prevalence of HTTPS
> interception:
> https://jhalderm.com/pub/papers/interception-ndss17.pdf
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Question about Baseline Requirements section #7.1.4.2

[Gervase Markham]

On 24/01/17 00:01, Peter Bowen wrote:
> I agree that the BRs could be clearer, but it seems to me that the
> only requirements are country and organization name.

Hi Peter,

Can you point me at which section requires those two fields?

Thanks,

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

Re: Suspicious test.com Cert Issued By GlobalSign

[Gervase Markham]

On 01/02/17 19:47, Doug Beattie wrote:
> 9/11/2015 11:41:20 - test.com added as a prevetted domains 

Who added this - a customer, or a GlobalSign employee?

Were customers permitted to add domains to the prevetted list in their
enterprise accounts without GlobalSign confirming that they actually own
it? Are they still?

Gerv

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

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

[Gervase Markham]

On 07/02/17 21:02, okaphone.elektron...@gmail.com wrote:
> You start by noticing "The scope of the BRs is a matter of
> debate..."
> 
> And then you use that same "scope of the BRs" in 1) to specify
> Mozilla's requirements. Isn't that somewhat strange, if what you are
> trying to do is solve some problems that are caused by the former?

It may seem that way, but no :-) The reason is that the BRs ban SHA-1
issuance entirely, so a CA cannot be advantaged if it tries to dodge
this policy by claiming "actually, this cert is within the scope of the
BRs and so your SHA-1 restrictions do not apply".

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

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

[Gervase Markham]

On 07/02/17 19:15, Jakob Bohm wrote:
>> Point 2 does not apply if the certificate is an OCSP signing certificate
>> manually issued directly from a root.
> 
> Should be point 1 (on OCSP signing certificate is an EE cert)

Nope, I'm fairly sure I mean point 2. Rules about intermediate certs
don't apply when there's no intermediate cert.

> 3) Any intermediate between the Mozilla trusted CA root and the issuing
> intermidiate:
> * Has an appropriate pathlen: constraint consistent with the pathlen to
> all its EE issuing lower intermediate certs.
> * Is used only for issuing lower intermediate certs, OCSP signing certs
> and CRLs.  The OCSP signing certs and CRLs being used exclusively for
> revocation checking certs issued by the intermediate itself.

Please provide rationale for your suggested changes.

>> CAs may only sign SHA-1 hashes over intermediate certificates which
>> chain up to roots in Mozilla's program if the certificate to be signed
>> is a duplicate of an existing SHA-1 intermediate certificate with the
>> only changes being all of:
>> * a new key (of the same size);
> 
> or larger
> 
>> * a new serial number (of the same length);
> 
> or longer

No; identical. The logic is that allowing length changes makes it more
possible for someone to construct a collision.

> None of the above applies to root certificates voluntarily
> withdrawn from the Mozilla root program.

This is implied everywhere.

> Root certificates previously withdrawn for this purpose are encouraged
> to report this fact to Mozilla by  and to maintain valid entries in
> the CCADB for such roots, all for the benefit of organizations that
> maintain or service software that are or interoperate with such older
> software.

This would be a different matter, and one for the CCADB policy. We would
need to have a very good reason for requiring CAs to keep information in
the CCADB which did not relate to our root program.

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

Re: Misissued/Suspicious Symantec Certificates

[Gervase Markham]

On 05/02/17 09:47, Gervase Markham wrote:
> On 05/02/17 06:20, Peter Gutmann wrote:
>> That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the
>> server is advertising.  Hey, it would be pretty funny if the cert auditors'
>> certs were broken, but it's just the browser complaining about something 
>> else.
> 
> That machine definitely needs a webserver upgrade.

I contacted CPA Canada and got the following response:

"Thanks for your kindly worded note. We are aware of the deficiencies
and have handed the issue over to the IT group at CPA Canada. They are
in the process of making changes but there have been some other issues
exposed in the process, for example, getting the program to operate on a
new server. The IT group is working on this project currently but at the
moment I don’t have a time frame for when changes can be made."

Gerv

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