Re: Concerns with Dun & Bradstreet as a QIIS

[Ryan Sleevi via dev-security-policy]

Thanks for raising this, Ian.

The question and concern about QIIS is extremely reasonable. As discussed
in past CA/Browser Forum activities, some CAs have extended the definition
to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS
services (they’re not; that’s using a DTP).

In the discussions, I proposed a comprehensive set of reforms that would
wholly remedy this issue. Given that the objective of OV and EV
certificates is nominally to establish a legal identity, and the legal
identity is derived from State power of recognition, I proposed that only
QGIS be recognized for such information. This wholly resolves differences
in interpretation on suitable QIIS.

However, to ensure there do not also emerge conflicting understandings of
appropriate QGIS - and in particular, since the BRs and EVGs recognize a
variety of QGIS’s with variable levels of assurance relative to the
information included - I further suggested that the determination of a QGIS
for a jurisdictional boundary should be maintained as a normative whitelist
that can be interoperably used and assessed against. If a given
jurisdiction is not included within that whitelist, or the QGIS is not on
it, it cannot be used. Additions to that whitelist can be maintained by the
Forum, based on an evaluation of the suitability of that QGIS for purpose,
and a consensus for adoption.

This would significantly reduce the risk, while also further reducing
ambiguities that have arisen from some CAs attempting to argue that
non-employees of the CA or QGIS, but which act as intermediaries on behalf
of the CA to the QGIS, are not functionally and formally DTPs and this
subject to the assessment requirements of DTPs. This ambiguity is being
exploited in ways that can allow a CA to nominally say it checked a QGIS,
but is relying on the word of a third-party, and with no assurance of the
system security of that third party.

Do you think such a proposal would wholly address your concern?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Concerns with Dun & Bradstreet as a QIIS

[Tim Hollebeek via dev-security-policy]

There have been previous discussions about this very issue at CA/Browser
Forum Validation Working Group meetings (see also draft Ballot 225).  I
think it is widely recognized that the rules around QIISs are far too weak
and in need of improvement.

I actually recently asked Kirk to add an item on the agenda for the upcoming
Face to Face meeting in Shanghai where we intend to push for the elimination
of the ability to rely upon unofficial information sources, especially Dun &
Bradstreet, for the reasons you cite.  It isn't a reliable information
source.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ian Carroll via dev-security-policy
> Sent: Wednesday, September 26, 2018 4:53 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Concerns with Dun & Bradstreet as a QIIS
> 
> Hi,
> 
> In April and May of this year, I attempted to change the address listed in
Dun
> & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an
> address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio).
I was
> wondering the extent of validation Dun & Bradstreet would do on the data.
> 
> To my surprise, they accepted my change request a couple days later. This
is
> concerning, of course, because D is a QIIS backing most EV certificate
> requests in the United States.
> 
> After this worked, I realized this was probably worth exploring more, so I
took
> my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested
> that Dun & Bradstreet change its address to "102 Townsend St San Francisco
> CA". You might notice that this is the same address as the real
Cloudflare, but
> with the street number incremented by one.
> 
> D accepted that change request as well. This meant I controlled a DUNS
> number that would resolve to a very similar address to CF, with my phone
> number on it.
> 
> I ordered two EV certificates from Comodo (order #s 136665865 and
> 141269115) with these fake DUNS numbers. I successfully completed the
> validation and callback process for the Cloudflare order, and Comodo was
> about to issue the certificate, but both of my orders were silently
deleted
> before they were about to be issued.
> 
> Comodo would not give me any information about why they (silently)
rejected
> my orders, but Dun & Bradstreet banned my account shortly after, so it is
safe
> to say they reported me after they realized something went wrong.
> 
> I think this is a strong indictment of D as a QIIS. The definition of a
QIIS, in
> my opinion, is incredibly lax, but "which is generally recognized as a
> dependable source of such information" is hard to meet here.
> 
> I am also, frankly, annoyed that Comodo seems to have silently discovered
> that D was unreliable and then ignored it without reporting it further.
I
> myself have been meaning to send this for a while, given I did this in
May, but
> various things have made it difficult for me to find the time.
> 
> Let me know if I can provide any further information.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/c3r2Ter8o50ppUH1pIlJlwoc7bmoCICI5nzl
> tycPf2k=?d=5ni4BvuKRPoeQ16JRlwwiqHkXFkBGUNLawHjFKnYSsf_1-
> W_uIoVE7PpGy6jmRBVcHjzciQQk9w61dUl2ViqRl9bL4r7h1J9S9DnsSgtX6UGfDf
> Rw3t__-hkOfmQMNa6AXM-enLMWQTxBynJj7o6Tlz6Akz4f-
> aW0KhOd4ZuAiOOxDs_WV7pO1wwY7wj9jCQ6GrgFJ7Zp3yZiiRnOGTKdbrRkzd9
> r7KzcqXr_4GkkZJ2Z78_8-
> Jmhw1XhrraBB_UID6gaAWdIrWxgcU4BJ4fj_Y5rGvyNW8yslAxFPRAz74O5WScx
> _QY7Z1ADHevtAXEsTB9FzRWQunaRP-OX8BfZHBtyGCEeZbV8b_s-
> eJ79m1giXYdCU-v98Yt1xsAk9pA1A-
> ythvQuBnksHG3tYf2auSXR0dbNaCDK46t6yIVXAQ%3D=https%3A%2F%2Flist
> s.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Concerns with Dun & Bradstreet as a QIIS

[Ian Carroll via dev-security-policy]

Hi,

In April and May of this year, I attempted to change the address listed in Dun 
& Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an address 
in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). I was 
wondering the extent of validation Dun & Bradstreet would do on the data.

To my surprise, they accepted my change request a couple days later. This is 
concerning, of course, because D is a QIIS backing most EV certificate 
requests in the United States. 

After this worked, I realized this was probably worth exploring more, so I took 
my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested that 
Dun & Bradstreet change its address to "102 Townsend St San Francisco CA". You 
might notice that this is the same address as the real Cloudflare, but with the 
street number incremented by one.

D accepted that change request as well. This meant I controlled a DUNS number 
that would resolve to a very similar address to CF, with my phone number on it.

I ordered two EV certificates from Comodo (order #s 136665865 and 141269115) 
with these fake DUNS numbers. I successfully completed the validation and 
callback process for the Cloudflare order, and Comodo was about to issue the 
certificate, but both of my orders were silently deleted before they were about 
to be issued.

Comodo would not give me any information about why they (silently) rejected my 
orders, but Dun & Bradstreet banned my account shortly after, so it is safe to 
say they reported me after they realized something went wrong.

I think this is a strong indictment of D as a QIIS. The definition of a QIIS, 
in my opinion, is incredibly lax, but "which is generally recognized as a 
dependable source of such information" is hard to meet here.

I am also, frankly, annoyed that Comodo seems to have silently discovered that 
D was unreliable and then ignored it without reporting it further. I myself 
have been meaning to send this for a while, given I did this in May, but 
various things have made it difficult for me to find the time.

Let me know if I can provide any further information.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: InfoCert Acquisition of Camerfirma

[David E. Ross via dev-security-policy]

On 9/26/2018 3:21 PM, Wayne Thayer wrote:
> I've held this discussion open for much longer than 3 weeks due to the
> qualified audit reports that were received from Camerfirma. Since no
> objections to the acquisition have been raised and the audit issues are
> being discussed separately [1][2], I would like to close this discussion
> and the corresponding bug [3] with a "positive conclusion" as required by
> policy section 8.1 If you have concerns with this action, please respond by
> the end of this week.

Should not a "positive conclusion" be withheld until the issues leading
to qualified reports are resolved?

-- 
David E. Ross


Too often, Twitter is a source of verbal vomit.  Examples include Donald
Trump, Roseanne Barr, and Elon Musk.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma's CP & CPS disclosure

[Wayne Thayer via dev-security-policy]

Hello Ramiro,

On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer  wrote:

> Thank you for this response Ramiro. I have copied this to the bug [1] and
> have described Mozilla's expectations for point-in-time audits that confirm
> that these issues have been resolved.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933
>
> On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> 7- List of steps your CA is taking to resolve the situation and ensure
>> such issuance will not be repeated in the future, accompanied with a
>> timeline of when your CA expects to accomplish these things.
>>
>> AC Camerfirma has made changes in the CP/CPS to fix the inconsistences
>> found by the auditor and will disseminate the documents and the new
>> procedures to avoid news problems in a future.
>> AC Camerfirma is working on correcting the imbalances detected and the
>> effective processes to ensure that the information offered by the OCSP and
>> the CRL is the same.
>> 2018-07-14 -> Qualified Audit Report
>> 2018-09-17 -> CPS & CP's new versions will be disclosed
>> New procedures and CPS/CP versions will be distributed among all affected
>> people in other to avoid new differences between CP/CPS
>> New procedures for self-assessment include full revision of OV
>> certificates.
>> Best control over changes in the BR version and modifications in AC
>> Camerfirma CP/CPS.
>> 2018-09-17 -> Finish a full review of the OCSP DDBB and synchronization
>> with the PKI DDBB.
>> 2018-09-24 -> fixed all inconsistences found. We've reviewed the complete
>> databases and checked the correct OCSP/PKI/CRL alignment, correcting the
>> problems found.
>> 2018-10-01 -> Technical control to avoid inconsistences. We've improving
>> the execution of the triggers and develop the controls that confirm their
>> correct operation.
>> 018-10-01 -> timely reports (weekly to monthly basic) to assure technical
>> controls are working and no new inconsistences are produced.
>>
>> Will you please provide an update on the remediation steps described
above, and timing for the point-in-time audit that will confirm that these
problems have been fixed?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: InfoCert Acquisition of Camerfirma

[Wayne Thayer via dev-security-policy]

I've held this discussion open for much longer than 3 weeks due to the
qualified audit reports that were received from Camerfirma. Since no
objections to the acquisition have been raised and the audit issues are
being discussed separately [1][2], I would like to close this discussion
and the corresponding bug [3] with a "positive conclusion" as required by
policy section 8.1 If you have concerns with this action, please respond by
the end of this week.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Xmr13-ZK0_c/kiyqqk7hCQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1463597

On Mon, Jul 30, 2018 at 5:47 PM Wayne Thayer  wrote:

> On Wed, Jul 18, 2018 at 1:56 PM Wayne Thayer  wrote:
>
>> I would like to begin a 3-week public discussion period for InfoCert's
>> acquisition of Camerfirma [1] as described in section 8.1 of the Mozilla
>> Root Store Policy. I believe that the intent of our policy in this scenario
>> is to identify and consider any risks introduced by the acquisition of
>> Camerfirma, and not to reevaluate Camerfirma's inclusion as if it were a
>> new CA. In that context, I will appreciate everyone's constructive input on
>> issues that may affect Mozilla's ongoing trust in InfoCert/Camerfirma. I
>> have included some additional information below.
>>
>> - Wayne
>>
>> Camerfirma answered the questions that I posed [2] about this acquisition
>> as follows:
>>
>> 
>
>>
>> Camerfirma has one open compliance bug [5] requesting full audit
>> information for a subordinate CA.
>>
>> Camerfirma has supplied the audit information for this subordinate CA.
>
> Camerfirma also recently issued two intermediates that were not disclosed
> within the required week [8][9].
>
> Camerfirma's 2018 audit statements are overdue - the prior period ended on
>> 14-April 2017, and new statements have not yet been supplied to Mozilla.
>> Last year's statements are still listed on the Camerfirma website [6].
>>
>> Camerfirma has supplied their 2018 audit reports:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1478933
>
> The WebTrust, BR, and EV reports all contain multiple qualifications. I
> would summarize the qualifications as follows:
> * Inconsistencies and omissions in CP/CPS documents which I would consider
> relatively minor.
> * Misissuances. The reports appear to be referring to those documented in
> bugs 1357067, 1390977, 1405815, 1431164, and 1443857.
> * Misissuance for "wildcard to immediate left of public suffix in SAN" was
> also reported. I found [10] but since those are for the .sener brand TLD,
> it is possible that Camerfirma issued them in compliance with BR 3.2.2.6.
> * Not meeting the BR requirement to revoke within 24 hours, presumably
> referencing bug 1390977.
> *The revocation time differs between the OCSP service and CRL for a few
> certificates, and the OCSP service responds "good" for some certificates
> revoked according to the CRL.
> * Failure to begin investigations of problem reports within 24 hours.
> * Failure to self-audit at least 3% of issued certificates each quarter.
>
> 
>
> [1]
>> https://infocert.digital/infocert-underwrites-a-capital-increase-to-acquire-51-of-the-spanish-ac-camerfirma/
>>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1463597
>>
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=986854
>>
> [4]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ
>>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1455147
>>
> [6] https://www.camerfirma.com/camerfirma/acreditaciones/
>>
> [7]
>> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_3.3.1_EN.pdf
>>
> [8]
>> https://crt.sh/?sha256=06a57d1cd5879fba2135610dd8d725cc268d2a6de8a463d424c4b9da89848696=mozilladisclosure
>
> [9]
>> https://crt.sh/?sha256=1defd59846cc2049ba1f1a74d3a8329d1357a2d47c1e1b0c15c27a8c60295455=mozilladisclosure
>>
> [10] https://crt.sh/?cablint=319=1778=2017-01-01
>
>
>
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services Root Inclusion Request

[Nick Lamb via dev-security-policy]

On Wed, 26 Sep 2018 16:03:58 +
Jeremy Rowley via dev-security-policy
 wrote:

> Note that I didn’t say Google controlled the policy. However, as a
> module peer, Google does have significant influence over the policy
> and what CAs are trusted by Mozilla. Although everyone can
> participate in Mozilla discussions publicly, it’s a fallacy to state
> that a general participant has similar sway or authority to a module
> peer.

I do not agree with this. I participate in m.d.s.policy as an individual
and I don't think there has ever been a situation where I felt I did
not have "similar sway or authority to a module peer".

Thinking back to, for example, TSYS, my impression was that my post on
the Moral Hazard from granting this exception had at least as much
impact as you could expect for any participant. Mozilla declined to
authorise the (inevitable, to such an extent I pointed out that it
would happen months before it did) request for yet another exception
when TSYS asked again.

I think my situation may be different from yours Jeremy in that even
when posting strictly in a personal capacity your "other hat" remains in
view. I don't really have another hat, I'm a Relying Party from the
Network. I want the Network to be able to Rely on the Web PKI and I
seek the Prevention of Future Harm to myself and other Relying Parties.
That lines up really well with Mozilla's goals (not quite perfectly
since Mozilla cares primarily about Firefox not generic Relying Parties)

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

Re: Google Trust Services Root Inclusion Request

[Wayne Thayer via dev-security-policy]

I'm disputing the conclusion that is being drawn from Jake's concerns,
rather than the concerns themselves. Primarily, I disagree with the
conclusion that because Google owns a browser with dominant market share
and - due to the substantial contributions they make here - because Google
has considerable influence in this community, they should not be allowed to
participate in our root program as a CA. Secondarily, I disagree that a
Google employee should not be a peer of this module due to the potential
for a conflict of interest.

Unpacking this conclusion in terms of policy it implies, I think the
argument being made is that any root store operator should be excluded from
membership in the Mozilla program as a CA, and any employee of a CA should
be prohibited from being a module peer. The argument is that this will
protect us from future conflicts of interest (there seems to be agreement
that the concern is hypothetical at this point).

My conclusion is that rather than creating somewhat arbitrary, exclusionary
rules, we can and should instead rely on the openness and inclusiveness of
our process to protect us from conflicts of interest. If Google attempts to
gain preferential treatment for their CA from Mozilla, our community can
and will identify it, reject it, and hold Mozilla accountable for acting in
their best interest.

On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley  >
> wrote:
>
> > I also should also emphasize that I’m speaking as Jeremy Rowley, not as
> > DigiCert.
> >
> >
> >
> > Note that I didn’t say Google controlled the policy. However, as a module
> > peer, Google does have significant influence over the policy and what CAs
> > are trusted by Mozilla. Although everyone can participate in Mozilla
> > discussions publicly, it’s a fallacy to state that a general participant
> > has similar sway or authority to a module peer. That’s the whole point of
> > having a separate class for peers compared to us general public.  With
> > Google acting as a CA and module peer, you now have one CA heavily
> > influencing who its competitors are, how its competitors operate, and
> what
> > its competitors can do.  Although I personally find that you never misuse
> > your power as a module peer, I can see how Jake has concerns that Google
> > (as a CA) has very heavy influence over the platform that has
> historically
> > been the CA watchdog (Mozilla).
> >
>
> Jeremy, I think this again deserves calling out, because this is
> misrepresenting what module peership does, as well as the CA relationship.
>
> I linked you to the definition of Module Ownership, which highlights and
> emphasizes that the module peer is simply a recognized helper. To the
> extent there is any influence, it is through the public discussions here.
> If your concern is that the title confers some special advantage, that's to
> misread what module peer is. If your concern is that the participation -
> which provides solid technical arguments as well as the policy alternatives
> - is influential, then what you're arguing against is public participation.
>
> You're presenting these as factual, and that's misleading, so I'd like to
> highlight what is actually entailed.
>
>
> > The circumstances are different between the scenarios you describe with
> > respect to the other browsers, as is market share.  If Microsoft wants to
> > change CAs (and they already use multiple), they can without impacting
> > public perception. If Apple wants to use another CA, they can without
> > people commenting how odd it is that Apple doesn’t use the Apple CA. With
> > Google controlling the CA and the Google browser, all incentive to
> > eliminate any misbehaving Google CA disappears for financial reasons,
> > public perception, and because Google can control the messaging (through
> > marketshare and influence over Mozilla policy). Note that there is
> > historical precedent for Google treating Google special – i.e. the
> > exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s
> > concerns should not be discarded so readily.
> >
>
> I can understand and appreciate why you have this perspective. I disagree
> that it's an accurate representation, and as shown by the previous message,
> it does not have factual basis. I think it's misleading to suggest that the
> concerns are being discarded, much like yours - they're being responded to
> with supporting evidence and careful analysis. However, they do not hold
> water, and while it would be ideal to convince you of this as well, it's
> equally important to be transparent about it.
>
> Your argument above seems to boil down to "People would notice if Google
> changed CAs, but not if Microsoft" - yet that's not supported (see,
> example, the usage of Let's Encrypt by Google, or the former usage of
> WoSign by Microsoft). Your argument about incentives entirely ignores 

Re: Google Trust Services Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley 
wrote:

> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
> DigiCert.
>
>
>
> Note that I didn’t say Google controlled the policy. However, as a module
> peer, Google does have significant influence over the policy and what CAs
> are trusted by Mozilla. Although everyone can participate in Mozilla
> discussions publicly, it’s a fallacy to state that a general participant
> has similar sway or authority to a module peer. That’s the whole point of
> having a separate class for peers compared to us general public.  With
> Google acting as a CA and module peer, you now have one CA heavily
> influencing who its competitors are, how its competitors operate, and what
> its competitors can do.  Although I personally find that you never misuse
> your power as a module peer, I can see how Jake has concerns that Google
> (as a CA) has very heavy influence over the platform that has historically
> been the CA watchdog (Mozilla).
>

Jeremy, I think this again deserves calling out, because this is
misrepresenting what module peership does, as well as the CA relationship.

I linked you to the definition of Module Ownership, which highlights and
emphasizes that the module peer is simply a recognized helper. To the
extent there is any influence, it is through the public discussions here.
If your concern is that the title confers some special advantage, that's to
misread what module peer is. If your concern is that the participation -
which provides solid technical arguments as well as the policy alternatives
- is influential, then what you're arguing against is public participation.

You're presenting these as factual, and that's misleading, so I'd like to
highlight what is actually entailed.


> The circumstances are different between the scenarios you describe with
> respect to the other browsers, as is market share.  If Microsoft wants to
> change CAs (and they already use multiple), they can without impacting
> public perception. If Apple wants to use another CA, they can without
> people commenting how odd it is that Apple doesn’t use the Apple CA. With
> Google controlling the CA and the Google browser, all incentive to
> eliminate any misbehaving Google CA disappears for financial reasons,
> public perception, and because Google can control the messaging (through
> marketshare and influence over Mozilla policy). Note that there is
> historical precedent for Google treating Google special – i.e. the
> exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s
> concerns should not be discarded so readily.
>

I can understand and appreciate why you have this perspective. I disagree
that it's an accurate representation, and as shown by the previous message,
it does not have factual basis. I think it's misleading to suggest that the
concerns are being discarded, much like yours - they're being responded to
with supporting evidence and careful analysis. However, they do not hold
water, and while it would be ideal to convince you of this as well, it's
equally important to be transparent about it.

Your argument above seems to boil down to "People would notice if Google
changed CAs, but not if Microsoft" - yet that's not supported (see,
example, the usage of Let's Encrypt by Google, or the former usage of
WoSign by Microsoft). Your argument about incentives entirely ignores the
incentives I just described to you previously - which look at public
perception, internet security, and ecosystem stability. Your argument about
influence over Mozilla policy has already been demonstrated as false and
misleading, but it seems you won't be convinced by that. And your
suggestion of special treatment ignores the facts of the situation (the
validation issues, the scoping of audits, that Apple and 2 other CAs were
also included in the exclusion), ignores the more significant special
treatment granted by other vendors (e.g. Apple's exclusion of a host of
mismanaged Symantec sub-CAs now under DigiCert's operational control), the
past precedent (e.g. the gradual distrust of WoSign/StartCom through
whitelists, of CNNIC through whitelists), and the public discussion
involved so entirely that it's entirely unfounded.

So I think your continued suggestion that it's being discarded so readily
is, again, misleading and inaccurate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Re: Google Trust Services Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

Hi Richard,

A few corrections:

On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan mentioned WoSign/StartCom and 360, so I like to say some words.
>
> First, I think your idea is not a proper metaphor because 360 browser
> can't compare to Google browser, Google browser have absolutely strong
> market share to say YES/NO to all CAs, but I am sure not to Google CA.
>

That wasn't the comparison. I was more highlighting how you actively
mislead (lied?) to the community about the relationship between the
entities, by trying to argue as separate entities. While Google Trust
Services is a separate legal entity, which is about ensuring there is a
firewall between these organizations, my concern about bringing it up was
because of how you actively mislead the community.


> Third, your comparison of Apple and Microsoft is also not correct, they
> use its own CA system for their own system use only, not for public, not to
> be a global public CA like Google.
>

I'm afraid this also misunderstands things. Microsoft does issue
certificates for end-users using its services (like Google). To the point
of the discussion, however, it was about the assumption and implication
that you cannot distrust an entity that operates a large web presence and
also a CA, or that browsers would play special favors to the CAs of their
properties, whether in-house or external. Both of these apply to all
browsers - arguably, even Mozilla (which uses certs from DigiCert as well,
either through the Amazon-branded sub-CA that DigiCert operates or directly
through DigiCert)


> Ryan, thank you for still remembering WoSign.
>

I think it will be very hard for the community to ever forget
https://wiki.mozilla.org/CA:WoSign_Issues
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

I also should also emphasize that I’m speaking as Jeremy Rowley, not as 
DigiCert.

 

Note that I didn’t say Google controlled the policy. However, as a module peer, 
Google does have significant influence over the policy and what CAs are trusted 
by Mozilla. Although everyone can participate in Mozilla discussions publicly, 
it’s a fallacy to state that a general participant has similar sway or 
authority to a module peer. That’s the whole point of having a separate class 
for peers compared to us general public.  With Google acting as a CA and module 
peer, you now have one CA heavily influencing who its competitors are, how its 
competitors operate, and what its competitors can do.  Although I personally 
find that you never misuse your power as a module peer, I can see how Jake has 
concerns that Google (as a CA) has very heavy influence over the platform that 
has historically been the CA watchdog (Mozilla). 

 

The circumstances are different between the scenarios you describe with respect 
to the other browsers, as is market share.  If Microsoft wants to change CAs 
(and they already use multiple), they can without impacting public perception. 
If Apple wants to use another CA, they can without people commenting how odd it 
is that Apple doesn’t use the Apple CA. With Google controlling the CA and the 
Google browser, all incentive to eliminate any misbehaving Google CA disappears 
for financial reasons, public perception, and because Google can control the 
messaging (through marketshare and influence over Mozilla policy). Note that 
there is historical precedent for Google treating Google special – i.e. the 
exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s 
concerns should not be discarded so readily. 

 

 

 

From: Ryan Sleevi  
Sent: Wednesday, September 26, 2018 12:43 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services Root Inclusion Request

 

(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going 
to emphasize that this response is in a personal capacity)



On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Jake's concern is legit if you believe certain assumptions. Criticizing his
rationale doesn't seem correct, especially since Google does indeed have a
root store. Although not traditional, Google runs a store of blacklisted CAs
(see Symantec), which is every bit as effective as controlling CA compliance
and operation as the inclusion process.

 

To be clear: Google does indeed operate root stores on a host of devices, 
including Android and ChromeOS, not to mention Google Cloud functionality.

 

FACT: As a browser, Google already interprets the CA/Browser requirements in
many ways via, intentionally or not.  The Google's policies, and how Google
implements Chrome are all closely watched by CAs and help dictate how we
interpret the various requirements.  

 

This fact combined with the assumption that Google will never distrust
itself jumps to a conclusion that Google will only interpreting the BRs in
Google CA's best interests. Why wouldn't they? Google is a for profit
company. Self-promotion is kind-of in the description.

 

The problem with this assumption, or at least what logically follows, is that 
every Browser would behave the same, beneficient towards the CA(s) they use for 
services. For example, Microsoft operates a root program, yet is also trusted 
by Mozilla through the subordinate CAs provided through the Baltimore 
Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates 
a root program, yet is also trusted by Mozilla through subordinate CAs provided 
through the GeoTrust hierarchy, which is owned by... DigiCert.

 

Google operates a root program, yet is also trusted by Mozilla through... the 
acquisition of key material (from GlobalSign) and the operation of independent 
roots.

 

If we accept this assumption as sound, then it seems the argument is that 
DigiCert can also never be distrusted, and interpretations will always be to 
the benefit of DigiCert, because to distrust DigiCert or take sanction would be 
to disrupt 'critical' services like Azure or iTunes.

 

Alternatively, one could argue/make assumptions that by virtue of Google 
previously having operated a subordinate under the GeoTrust hierarchy 
(DigiCert, formerly Symantec), that they've demonstrated it's possible to 
operate as subordinate or root. They demonstrably took steps regarding the 
Symantec hierarchy, even as it was the basis for trust of Google services. In 
that model, if Google CA were to take actions detrimental to the ecosystem, 
Google may interpret the BRs in the Internet trust and stabilities best 
interests, distrust the Google CA, and force Google to transition to an 
alternative solution precisely to avoid the alternative.

 

The problem here is these are all assumptions that 

RE: Re: Google Trust Services Root Inclusion Request

[Richard Wang via dev-security-policy]

Ryan mentioned WoSign/StartCom and 360, so I like to say some words.

First, I think your idea is not a proper metaphor because 360 browser can't 
compare to Google browser, Google browser have absolutely strong market share 
to say YES/NO to all CAs, but I am sure not to Google CA.

Second, I think Google to be a global public CA is a wrong decision, this is 
the same situation that one person is the athlete and the judge, how to 
guarantee the fair? This two business have conflict of interest.

Third, your comparison of Apple and Microsoft is also not correct, they use its 
own CA system for their own system use only, not for public, not to be a global 
public CA like Google.

So, I think accepting Google root to Mozilla trust store don't benefit for 
anyone except Google only, not for the Internet security community, not for the 
CA industry and not for end users.   

Ryan, thank you for still remembering WoSign. 

Best Regards,

Richard Wang

 Original message 
From: Ryan Sleevi via dev-security-policy 
Received: 2018-09-26 14:48:28
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
Subject: Re: Google Trust Services Root Inclusion Request


(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm
going to emphasize that this response is in a personal capacity)

On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Jake's concern is legit if you believe certain assumptions. Criticizing his
> rationale doesn't seem correct, especially since Google does indeed have a
> root store. Although not traditional, Google runs a store of blacklisted
> CAs
> (see Symantec), which is every bit as effective as controlling CA
> compliance
> and operation as the inclusion process.
>

To be clear: Google does indeed operate root stores on a host of devices,
including Android and ChromeOS, not to mention Google Cloud functionality.


> FACT: As a browser, Google already interprets the CA/Browser requirements
> in
> many ways via, intentionally or not.  The Google's policies, and how Google
> implements Chrome are all closely watched by CAs and help dictate how we
> interpret the various requirements.
>


> This fact combined with the assumption that Google will never distrust
> itself jumps to a conclusion that Google will only interpreting the BRs in
> Google CA's best interests. Why wouldn't they? Google is a for profit
> company. Self-promotion is kind-of in the description.
>

The problem with this assumption, or at least what logically follows, is
that every Browser would behave the same, beneficient towards the CA(s)
they use for services. For example, Microsoft operates a root program, yet
is also trusted by Mozilla through the subordinate CAs provided through the
Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly,
Apple operates a root program, yet is also trusted by Mozilla through
subordinate CAs provided through the GeoTrust hierarchy, which is owned
by... DigiCert.

Google operates a root program, yet is also trusted by Mozilla through...
the acquisition of key material (from GlobalSign) and the operation of
independent roots.

If we accept this assumption as sound, then it seems the argument is that
DigiCert can also never be distrusted, and interpretations will always be
to the benefit of DigiCert, because to distrust DigiCert or take sanction
would be to disrupt 'critical' services like Azure or iTunes.

Alternatively, one could argue/make assumptions that by virtue of Google
previously having operated a subordinate under the GeoTrust hierarchy
(DigiCert, formerly Symantec), that they've demonstrated it's possible to
operate as subordinate or root. They demonstrably took steps regarding the
Symantec hierarchy, even as it was the basis for trust of Google services.
In that model, if Google CA were to take actions detrimental to the
ecosystem, Google may interpret the BRs in the Internet trust and
stabilities best interests, distrust the Google CA, and force Google to
transition to an alternative solution precisely to avoid the alternative.

The problem here is these are all assumptions that rest on ignoring
pertinent details.


> FACT: Google is a module peer in Mozilla NSS, which means Google has
> significant influence over BR interpretation, the penalties related to CA
> mis-issuance, and the requirements a CA has for operating within the space.
> This gives one CA a lot of influence over how Mozilla treats the other
> CAs.
> The change in paradigm means a reasonable person (like Jake) could be
> concerned with potential obfuscation of problems, a loss of policy
> enforcement, and various other nefarious acts. I think most of us Mozilla
> users see Mozilla as a watch-dog of the Internet so this combination of
> Browser-CA-module peer reasonably causes unease.
>

Unfortunately, this FACT isn't correct - it doesn't reflect the Module
Ownership Governance System, 

Re: Google Trust Services Root Inclusion Request

[Fotis Loukos via dev-security-policy]

On 26/09/2018 09:43 πμ, Ryan Sleevi via dev-security-policy wrote:
> (While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm
> going to emphasize that this response is in a personal capacity)
> 
> On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Jake's concern is legit if you believe certain assumptions. Criticizing his
>> rationale doesn't seem correct, especially since Google does indeed have a
>> root store. Although not traditional, Google runs a store of blacklisted
>> CAs
>> (see Symantec), which is every bit as effective as controlling CA
>> compliance
>> and operation as the inclusion process.
>>
> 
> To be clear: Google does indeed operate root stores on a host of devices,
> including Android and ChromeOS, not to mention Google Cloud functionality.
> 
> 
>> FACT: As a browser, Google already interprets the CA/Browser requirements
>> in
>> many ways via, intentionally or not.  The Google's policies, and how Google
>> implements Chrome are all closely watched by CAs and help dictate how we
>> interpret the various requirements.
>>
> 
> 
>> This fact combined with the assumption that Google will never distrust
>> itself jumps to a conclusion that Google will only interpreting the BRs in
>> Google CA's best interests. Why wouldn't they? Google is a for profit
>> company. Self-promotion is kind-of in the description.
>>
> 
> The problem with this assumption, or at least what logically follows, is
> that every Browser would behave the same, beneficient towards the CA(s)
> they use for services. For example, Microsoft operates a root program, yet
> is also trusted by Mozilla through the subordinate CAs provided through the
> Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly,
> Apple operates a root program, yet is also trusted by Mozilla through
> subordinate CAs provided through the GeoTrust hierarchy, which is owned
> by... DigiCert.
> 
> Google operates a root program, yet is also trusted by Mozilla through...
> the acquisition of key material (from GlobalSign) and the operation of
> independent roots.
> 
> If we accept this assumption as sound, then it seems the argument is that
> DigiCert can also never be distrusted, and interpretations will always be
> to the benefit of DigiCert, because to distrust DigiCert or take sanction
> would be to disrupt 'critical' services like Azure or iTunes.
> 
> Alternatively, one could argue/make assumptions that by virtue of Google
> previously having operated a subordinate under the GeoTrust hierarchy
> (DigiCert, formerly Symantec), that they've demonstrated it's possible to
> operate as subordinate or root. They demonstrably took steps regarding the
> Symantec hierarchy, even as it was the basis for trust of Google services.
> In that model, if Google CA were to take actions detrimental to the
> ecosystem, Google may interpret the BRs in the Internet trust and
> stabilities best interests, distrust the Google CA, and force Google to
> transition to an alternative solution precisely to avoid the alternative.
> 
> The problem here is these are all assumptions that rest on ignoring
> pertinent details.

I would like to add that based on previous experience, Google has built
a firewall between the Chrome and the rest of the teams. And it seems
that there is a special treatment by the Chrome team, but not the one
stated. Google trying to set the example is more strict when it comes to
their own services. For example, you can see the history behind freezing
the google-run Aviator log. Even though other logs, such as the ones run
by Venafi and the DigiCert, had single MMD violations and were not
disqualified, Google decided to freeze Aviator. I think this is a clear
indication that Google does not favor their own services.

Regards,
Fotis

> 
> 
>> FACT: Google is a module peer in Mozilla NSS, which means Google has
>> significant influence over BR interpretation, the penalties related to CA
>> mis-issuance, and the requirements a CA has for operating within the space.
>> This gives one CA a lot of influence over how Mozilla treats the other
>> CAs.
>> The change in paradigm means a reasonable person (like Jake) could be
>> concerned with potential obfuscation of problems, a loss of policy
>> enforcement, and various other nefarious acts. I think most of us Mozilla
>> users see Mozilla as a watch-dog of the Internet so this combination of
>> Browser-CA-module peer reasonably causes unease.
>>
> 
> Unfortunately, this FACT isn't correct - it doesn't reflect the Module
> Ownership Governance System, which is covered in
> https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ .
> A peer isn't the decision maker - that rests with the Owner, particularly
> for matters of things like policy.
> 
> We could discuss the semantics of Google vs Google Trust Services, but I
> fully acknowledge that it would go over about as well as WoSign vs 

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[josselin.allemandou--- via dev-security-policy]

Hello

Thank you for your exchanges. We hope that the additions below will answer your 
questions.

Was the action required to manually override the CAA validation failure
different from what would be required if the CAA validation had succeeded? 
Could an operator have just "clicked the same button they always clicked",
and have the CAA validation failure overridden?  Or was there a separate
sequence of UI interactions required to override a CAA validation failure?

This answer does not address the controls in place at the time of the
misissuance.  Any action which an operator can manually take should be able
to be audited for correctness, but I don't see any mention of that being a
possibility in your response.  I take that to mean that there are no
functional audit logs, or at least that there are no effective audits
(sampling or otherwise) of those logs, for decisions and actions undertaken
by registration agents.

The check on the authorization to be issued for the organization was the only 
one that combined both the verification of the consent form and the 
verification of DNS CAA alerts. The operator could view the alert but the same 
validation button was used to proceed to the next step, whether the DNS CAA is 
valid or not.
Each operation performed by an operator is traced so that it can be audited. 
The periodic audits of registration requests are also intended to ensure the 
conduct of controls by RA and the conformity of their results.

This sounds like there may have been a misunderstanding in the BR
description of CAA validation.

What specific language in the BRs surrounding CAA validation caused you to
believe that successful CAA validation was optional in the presence of other
forms of consent?

What changes do you propose in the language of the CAA validation
requirements in the BRs to ensure that no other CA could possibly
misunderstand the CAA validation requirements?

We have no improvement to issue regarding BRs. We understood the requirement 
and implemented the DNS CAA control but we made two errors: 
- The first is to have assessed that the existing control having the same 
purpose, made it possible to cover the risks and requirements related to the 
control of the DNS CAA. This decision led to wrongly allow RA operators to 
validate this checkpoint despite DNS CAA alerts.
- The second is to have accumulated these two controls (consent + DNS CAA) in 
the same validation step because they had the same objective, and this without 
imposing that the DNS CAA negative result be blocking. 

Have you proposed those changes to the CA/B Forum, to improve the BRs for
all participants?  If not, why not?

We would recommend to the other CAs to segment each control even if their 
objective is the same, in order to be sure that the result of each control is 
taken into account and can not be circumvented under the pretext that a 
control, having the same purpose, is positive.

Regarding the control on obtaining the consent of the legal representative, it 
is imposed by a national standard that is gradually aligned with the guidelines 
of the CA\B Forum, but this standard unfortunately does not evolve quickly due 
to administrative constraints.

We did not perceive the interest of suggesting the use of this method knowing 
that it is imposed only on the scale of France and not for other international 
CA and that the control of the DNS CAA had in our opinion the same purpose .

We want as much as possible that the different national, European and 
international standards are harmonized in order to avoid the implementation of 
different controls but for the same purposes.

That the BRs have been misunderstood in this fashion is somewhat concerning. 
it suggests that there may be other misunderstandings latent in your systems
and processes, which haven't surfaced because they haven't (yet) led to an
identified misissuance or other incident.

What steps have you taken, or are you planning on taking, to address
possible misunderstandings of the BRs or Mozilla policy that may cause
Certigna to unintentionally misissue a certificate or suffer from some other
incident?

In what ways have you modified your monitoring, internal audits, and annual
audits by a certification body in light of the fact that the previous
editions of those were manifestly insufficient to identify the
non-compliance of your CAA-related procedures ?

To address the two errors mentioned above, we have updated the RA Validation 
Portal to separate the DNS CAA control and make it blocking automatically. The 
other validation steps are well separated.

In addition to the audit we conducted following the DNS CAA incident, we are 
conducting the annual internal audit of our practices in order to verify, as 
each year, their compliance with the requirements of the BRs and EV Guidelines. 
It is also expected that new auditors will be involved, both in the internal 
audit and in the certification audit planned for this year.

We also 

Re: Google Trust Services Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm
going to emphasize that this response is in a personal capacity)

On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Jake's concern is legit if you believe certain assumptions. Criticizing his
> rationale doesn't seem correct, especially since Google does indeed have a
> root store. Although not traditional, Google runs a store of blacklisted
> CAs
> (see Symantec), which is every bit as effective as controlling CA
> compliance
> and operation as the inclusion process.
>

To be clear: Google does indeed operate root stores on a host of devices,
including Android and ChromeOS, not to mention Google Cloud functionality.


> FACT: As a browser, Google already interprets the CA/Browser requirements
> in
> many ways via, intentionally or not.  The Google's policies, and how Google
> implements Chrome are all closely watched by CAs and help dictate how we
> interpret the various requirements.
>


> This fact combined with the assumption that Google will never distrust
> itself jumps to a conclusion that Google will only interpreting the BRs in
> Google CA's best interests. Why wouldn't they? Google is a for profit
> company. Self-promotion is kind-of in the description.
>

The problem with this assumption, or at least what logically follows, is
that every Browser would behave the same, beneficient towards the CA(s)
they use for services. For example, Microsoft operates a root program, yet
is also trusted by Mozilla through the subordinate CAs provided through the
Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly,
Apple operates a root program, yet is also trusted by Mozilla through
subordinate CAs provided through the GeoTrust hierarchy, which is owned
by... DigiCert.

Google operates a root program, yet is also trusted by Mozilla through...
the acquisition of key material (from GlobalSign) and the operation of
independent roots.

If we accept this assumption as sound, then it seems the argument is that
DigiCert can also never be distrusted, and interpretations will always be
to the benefit of DigiCert, because to distrust DigiCert or take sanction
would be to disrupt 'critical' services like Azure or iTunes.

Alternatively, one could argue/make assumptions that by virtue of Google
previously having operated a subordinate under the GeoTrust hierarchy
(DigiCert, formerly Symantec), that they've demonstrated it's possible to
operate as subordinate or root. They demonstrably took steps regarding the
Symantec hierarchy, even as it was the basis for trust of Google services.
In that model, if Google CA were to take actions detrimental to the
ecosystem, Google may interpret the BRs in the Internet trust and
stabilities best interests, distrust the Google CA, and force Google to
transition to an alternative solution precisely to avoid the alternative.

The problem here is these are all assumptions that rest on ignoring
pertinent details.


> FACT: Google is a module peer in Mozilla NSS, which means Google has
> significant influence over BR interpretation, the penalties related to CA
> mis-issuance, and the requirements a CA has for operating within the space.
> This gives one CA a lot of influence over how Mozilla treats the other
> CAs.
> The change in paradigm means a reasonable person (like Jake) could be
> concerned with potential obfuscation of problems, a loss of policy
> enforcement, and various other nefarious acts. I think most of us Mozilla
> users see Mozilla as a watch-dog of the Internet so this combination of
> Browser-CA-module peer reasonably causes unease.
>

Unfortunately, this FACT isn't correct - it doesn't reflect the Module
Ownership Governance System, which is covered in
https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ .
A peer isn't the decision maker - that rests with the Owner, particularly
for matters of things like policy.

We could discuss the semantics of Google vs Google Trust Services, but I
fully acknowledge that it would go over about as well as WoSign vs StartCom
vs Qihoo 360.

We could discuss https://wiki.mozilla.org/CA/Policy_Participants and its
set of disclosures, but I'm sure some people will find that unsatisfying.

What is perhaps most relevant is to highlight the fact that these questions
of interpretation - of BRs or policies - happen on the list, that the
module owner is the decision maker, and that public participation is fully
welcomed, whether peers or otherwise. In that model - of transparency -
doesn't support the claims being presented here as 'fact', and instead
highlights them as 'assumption's that they are.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy