RE: GoDaddy Misissuance Action Items

[Wayne Thayer via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy


> Here is our proposed remediation plan for GoDaddy.
> 
> 1) As with all CAs, update all their domain validation code to use one of the 
> 10
> approved methods;
> 
> 2) Implement comprehensive automated testing for their domain validation
> code for all issuance systems;
> 
> 3) Make sure those tests automatically run when any change is made to the
> code, before deployment, such that deployment is gated on a pass;
> 
> 4) Get a statement from their auditors that these tests have been created
> and positioned correctly in the deployment workflow.
> 
> All steps to be completed within 3 months.
> 
> Comments on this plan are welcome, including from GoDaddy.
>

Gerv - this makes sense and it is GoDaddy's intent to perform these steps 
within 3 months.

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

Re: Intermediates Supporting Many EE Certs

[Nick Lamb via dev-security-policy]

On Monday, 13 February 2017 22:40:45 UTC, Steve Medin  wrote:
> With de facto use of AIA, there is no issuer installation on the server that 
> could be improper. Proper is defined at the moment, either by cache or 
> discovery hints.

Much as I should like ubiquitous ambient Internet to be a ground truth, the 
reality is that clients connecting to a TLS server today don't necessarily have 
access in order to resolve URLs baked into AIA. Indeed in many cases (including 
for products sold by your own company, Symantec) the whole reason the client is 
talking to this particular server is in order to get access _to_ the Internet.

As a result, and indeed exactly as we see today in the wild, trying to "paper 
over" this gap from the client cannot work reliably.
___
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 via dev-security-policy]

On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Steve,
>
> On 12/02/17 15:27, Steve Medin wrote:
> > A response is now available in Bugzilla 1334377 and directly at:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8836487
>
> Thank you for this timely response. Mozilla continues to expect answers
> to all reasonable and polite questions posed in our forum, and is happy
> that Symantec is taking this approach.


Indeed Steve, thank you for your continued attention as we try to gain the
information and understanding necessary to determine how best to protect
users from misissued certificates.

I note that Symantec's answer to question 1 in [1] reiterates that, in
Symantec's view, the set of misissuance previously was solely related to a
specific internal tool, and as such, the remediation steps Symantec engaged
in focused on the process and controls related to that tool.

I highlight this because it seems difficult to understand the distinction
between the previous event and this current event, and understanding that
distinction seems relevant to understanding whether the steps Symantec took
previously were reasonable and complete to address this set of issues and
the community trust, as well as understanding the steps Symantec is
proposing or has taken in response to this current set of issues.

In the previous misissuance event, my understanding is that Symantec
asserts that the whole totality of the misissuance was related to a single,
specific tool. Symantec's initial response [2] was to assert that the issue
was limited to rogue actions of a few individuals contrary to Symantec's
policies and procedures. The proposed remediation of this was a termination
of relationship with those specific individuals. However, it was pointed
out by browsers based on a simple cursory examination that such a statement
was not consistent with the data - that the full set of issues were not
identified by Symantec in their initial investigation, and only upon
prompting by Browsers with a specific deadline did Symantec later recognize
the scope of the issues. In recognizing the scope, it was clear that the
issues did not simply relate to the use of a particular tool, but also to
the practices of employees with respect to asserting that things were
correct when they were not. A specific example is that the role of
Validation Specialist - which is tasked with independently reviewing the
certificate request for non-compliance - was designed in such a way that it
could be bypassed or overridden without following the appropriate policies.
These were actions independent of any particular tooling.

These issues were then amplified by the fact that Symantec was failing to
ensure that its policies and practices adhered to the appropriate version
of the Baseline Requirements, and that employees and staff were trained on
the appropriateness of ensuring the appropriate policies were followed,
regardless of the tools being employed.

In response to this issue, Symantec took a series of corrective steps, such
as:
- A comprehensive review of its Policies and Practices to ensure compliance
with the Baseline Requirements, as requested in [3] (and available at [4])
- The establishment of a centralized Compliance team to ensure compliance
across Symantec branded-CAs
- Internal training, which on the basis of [1] appears to have been limited
to a specific tool, rather than to the overall auditable criteria or
policies


In the current misissuance, my understanding is that Symantec asserts that
the totality of the misissuance was related to RAs. Symantec's initial
response to the set of questions posed by Google [5] indicated that " At
this time we do not have evidence that warrants suspension of privileges
granted to any other RA besides CrossCert" in the same message that
provided the CP/CPS for other RAs besides CrossCert, and itself a follow-up
to Symantec's initial response to the Mozilla community, [6], which
acknowledged for the potential of audit issues in the statement "We are
reviewing E’s audit work, including E’s detailed approach to
ascertaining how CrossCert met the required control objectives.". This
appears to be similar to the previous event, in that the proposed
remediation was first a termination of relationship with specific
individuals. However, in Symantec's most recently reply, [1], it seems that
again, on the basis of browser questions from a simple cursory examination
that such a statement was not consistent with the data - that is, that the
full set of issues were not identified by Symantec in their initial
investigation, and only upon prompting by Browsers with a specific deadline
did Symantec later recognize the scope of the issues. In recognizing the
scope, it was clear that the issues did not simply relate to the use of a
particular RA or auditor, but also to the practices of RAs with respect to
asserting things were correct when they 

Re: GoDaddy Misissuance Action Items

[Santhan Raj via dev-security-policy]

On Monday, February 13, 2017 at 3:14:06 PM UTC-8, Santhan Raj wrote:
> On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
> 
> > That is why, despite some IPR-related tangles, Mozilla will be requiring
> > in its next CA Communication that all CAs move to using only those
> > documented methods in a fairly short timeframe, regardless of what the
> > BRs say. CAs may wish to not wait for that communication to arrive
> > before starting to adapt their systems.
> 
> Grev,
> 
> One thing to highlight here is that the WebTrust audits are performed against 
> the BRs and not against the root program requirements. I.e., unless ballot 
> 169 makes it to the BRs, a (naughty) CA may still chose to use "any other 
> method" and it will not be flagged in the audit report, provided they 
> disclose as such in the CP/CPS. This means, Mozilla will have to review 
> (each) CA's CP/CPS to determine whether it validates _only_ using methods 
> specified in "the documented methods" and will have to do so for each CP/CPS 
> update. So hopefully 169  makes it's way to BR soon.
> 
> -Santhan

And sorry I misspelled you name!!!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Misissuance Action Items

[Santhan Raj via dev-security-policy]

On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:

> That is why, despite some IPR-related tangles, Mozilla will be requiring
> in its next CA Communication that all CAs move to using only those
> documented methods in a fairly short timeframe, regardless of what the
> BRs say. CAs may wish to not wait for that communication to arrive
> before starting to adapt their systems.

Grev,

One thing to highlight here is that the WebTrust audits are performed against 
the BRs and not against the root program requirements. I.e., unless ballot 169 
makes it to the BRs, a (naughty) CA may still chose to use "any other method" 
and it will not be flagged in the audit report, provided they disclose as such 
in the CP/CPS. This means, Mozilla will have to review (each) CA's CP/CPS to 
determine whether it validates _only_ using methods specified in "the 
documented methods" and will have to do so for each CP/CPS update. So hopefully 
169  makes it's way to BR soon.

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

Re: Intermediates Supporting Many EE Certs

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 13, 2017 at 11:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Patrick, thanks, it appears my attempt at brevity produced density.
>
> - No amount of mantra, training, email notification, blinking text and
> certificate installation checkers make 100% of IT staff who install
> certificates on servers aware that issuing CAs change and need to be
> installed with the server certificate when they do.
> - Many servers do not support PKCS#7 installation.
> - When you roll an intermediate issuer and you modify the end entity
> certificate's AIA CA Issuers URI at the same time, the server presents an
> EE
> to the browser that provides a remedy to path validation failure.
> - The browser does its normal path discovery using cached discovered
> intermediates.
> - At rollover, the browser doesn't find the EE's issuer cached locally.
> - The browser chases AIA to the issuer that the EE asserts is its issuer,
> validates that, and caches the issuer for another  years.
> It's a one-validation latency cost per end user given cached path
> discovery.
>

In the absence of AIA, this quickly becomes discoverable for servers. The
only reason it represents a burden on CAs today is precisely because of
customers' (inadvertant) reliance on AIA to correct for server
misconfiguration.

As mentioned, I'm a strong proponent of AIA - I think it serves a valuable
role in ecosystem agility for root migrations - but I don't think it's
necessarily good for users when it's used to paper over (clear) server
misconfigurations, which is the situation you describe - where the path
from the EE to the Intermediate is improper. I'm more thinking about
situations for where the Intermediate to Root path may change, in order to
accommodate changes in the Root (from Root 1 to Root 2).

Ultimately, it seems like it's a question of whether it's "too burdensome"
to expect servers properly configure their TLS certificate, therefore, the
argument is browser should employ logic to obviate that need. However,
given tools like CFSSL, is that really a good or compelling argument -
particularly one to suggest it's a gating factor for improvement? Isn't it
largely a question of how CAs engage with their customers for the
provisioning and deployment of certificates, rather than a holistic
ecosystem issue (of which I consider root migration to be part of the
latter)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Intermediates Supporting Many EE Certs

[Steve Medin via dev-security-policy]

Patrick, thanks, it appears my attempt at brevity produced density.

- No amount of mantra, training, email notification, blinking text and
certificate installation checkers make 100% of IT staff who install
certificates on servers aware that issuing CAs change and need to be
installed with the server certificate when they do.
- Many servers do not support PKCS#7 installation.
- When you roll an intermediate issuer and you modify the end entity
certificate's AIA CA Issuers URI at the same time, the server presents an EE
to the browser that provides a remedy to path validation failure.
- The browser does its normal path discovery using cached discovered
intermediates.
- At rollover, the browser doesn't find the EE's issuer cached locally.
- The browser chases AIA to the issuer that the EE asserts is its issuer,
validates that, and caches the issuer for another  years.
It's a one-validation latency cost per end user given cached path discovery.

Recently, we renewed a subordinate under the Federal Bridge CA and we
deployed trust across the community by updating a JBoC PKCS#7 file
referenced by the CA Issuers AIA. Granted, this is what some may call a
cross-certificate rather than subordination, but my point is that the end
entities that point to the .p7c enable peers and clients to discover path of
FBCA > SSP Gen 1 CA > EE as easily as FBCA > SSP Gen 2 CA > EE. 


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Patrick Figel via dev-security-policy
> Sent: Monday, February 13, 2017 2:10 PM
> To: r...@sleevi.com
> Cc: Gervase Markham ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Intermediates Supporting Many EE Certs
> 
> On 13/02/2017 18:25, Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Getting all user agents with interest is issuance limits to implement
> >> the CA Issuers form of AIA for dynamic path discovery and educating
> >> server operators to get out of the practice of static chain
> >> installation on servers would make CA rollovers fairly fluid and less
> >> subject to operator error of failing to install the proper
intermediate.
> >
> >
> > Can you explain more to support that statement?
> >
> > The issue that Gerv is discussing is primarily related to intermediate
> > issuance; a CA an easily roll over to a new intermediate and provide
> > their customers a holistic chain that represents a path to a Mozilla
> > root. The issue you describe - with AIA fetching - is one primarily
> > restricted to handling _root_ rollover, not _intermediate_ rollover;
> > that is, when you're constructing an alternative trust path for a set
> > of existing certificates, rather than, as Gerv raised, ensuring that
> > new certificates come from a single ('new') trust path once the
> > existing intermediate has been 'exhausted'.
> >
> > While a strong proponent of AIA, I don't believe your argument here is
> > relevant, although I'm quite happy to understand what technical
> > criteria exist that make you believe it would be beneficial to address
> > this specific problem.
> 
> I suspect many CAs would be reluctant to rotate intermediates regularly
> because updating the intermediate certificate would be yet another thing
> that server administrators can get wrong during renewal. Data from Chrome
> shows that incorrect or missing intermediates account for 10-30% of all
> certificate validation errors depending on platform[1], though I'm
guessing
> missing intermediates would account for most of that.
> 
> Let's Encrypt switched to a new intermediate certificate about a year ago.
> Despite plenty of warnings that it may change at any time and a protocol
that
> allowed retrieving the intermediate certificate programmatically, there
were
> still a number of clients and guides with static intermediates out there,
which
> caused breakage for some sites once they renewed. This is the main reason
> why later versions of the ACME draft switched to delivering the end-entity
> certificates and intermediates as one file by default.
> 
> Having support for AIA fetching in all major browsers would reduce the
> impact of such misconfigurations. IIRC the only browsers that currently
don't
> do this are Firefox and Chrome on Android, though the latter seems to have
> plans to change this.
> 
> Something else that needs to be considered is how it affects HPKP
> deployment. I don't know if there are any CAs out there who recommend
> pinning to (not-customer-specific) intermediates, but if there are any, we
> might need either an exemption for renewals or make sure CAs recommend
> pins that aren't affected by the rotation policy. I'd be interested in the
CA
> perspective on this; perhaps the lack of HPKP adoption and CA
> documentation on this topic makes this a 

Re: Intermediates Supporting Many EE Certs

[Nick Lamb via dev-security-policy]

On Monday, 13 February 2017 16:18:46 UTC, Steve Medin  wrote:
> Getting all user agents with interest is issuance limits to implement the CA 
> Issuers form of AIA for dynamic path discovery and educating server operators 
> to get out of the practice of static chain installation on servers would make 
> CA rollovers fairly fluid and less subject to operator error of failing to 
> install the proper intermediate.

Rather than teaching the User Agents about AIA path discovery, surely if you're 
concerned about operator error it makes more sense to teach the Servers about 
AIA instead ? I don't know if any TLS Server vendors read m.d.s.policy (they 
probably should) but I'd suggest they're the best people to reach out to.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediates Supporting Many EE Certs

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

On 2/13/2017 8:17 AM, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement
> the CA Issuers form of AIA for dynamic path discovery and educating
> server operators to get out of the practice of static chain
> installation on servers would make CA rollovers fairly fluid and less
> subject to operator error of failing to install the proper
> intermediate.

That is all one, very long sentence, far too long to really understand.
On top of that, I think
> with interest is issuance limits
should have been
> with interest in issuance limitsbut the sentence is so long, I am not sure.

-- 
David E. Ross


Paraphrasing Mark Twain, who was quoting someone else:
There are three kinds of lies: lies, damned lies, and
alternative truths.
___
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 via dev-security-policy]

On 13/02/17 14:34, Doug Beattie wrote:
> This was for  GlobalSign account used for testing, so it was a
> GlobalSIgn employee.  Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.

OK, then I'm a bit confused. You say this was a "managed service
account"; does such an account belong to a customer? If so, let's call
them company Foo.

> 9/11/2015 11:41:20 - test.com added as a prevetted domains

i.e. a GlobalSign employee added test.com to the account of company Foo.

> 9/11/2015 11:50 - Order received by CA

i.e. Company Foo places an order for a test.com cert. (You say
"received", so it didn't come from internally?)

How did Company Foo know it was OK to order such a cert? And why would
they do so?

Gerv



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

Re: GoDaddy Misissuance Action Items

[Gervase Markham via dev-security-policy]

On 13/02/17 16:41, Nick Lamb wrote:
> GoDaddy came up with). Thus, even though some of the methods from
> Ballot 169 are not included in the Baseline Requirements today,
> Mozilla intends to oblige root programme members to pick from those
> ten methods.

Yes. And this is permitted by the BRs because they currently have an
"any other method" method, which could cover any of the ones whose
actual text is missing.

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

Re: GoDaddy Misissuance Action Items

[Gervase Markham via dev-security-policy]

On 13/02/17 14:34, Nick Lamb wrote:
> I don't think Ballot 169 represents best practices per se. Instead as
> with the rest of the Baseline Requirements what we have here are
> _minimums_, we aren't asking that CAs should do no more than what is
> described, but that they must do at least what is described.

Well, OK. That wasn't really the focus of the statement. I suspect that
the ballot 169 methods are bar-raising for most CAs, even if they aren't
yet as watertight as they could be.

> Anyway, I have a nitpick for your GoDaddy remediation plan. I think
> in item (1) it's not clear that it's fine for a CA to choose to
> implement many or even all ten methods, and even for them to have
> other methods - what's important is that for any particular name
> validated their process ensures at least one of the ten Ballot 169
> methods was used.

That is my intent; I'm happy to make that clear.

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

Re: GoDaddy Misissuance Action Items

[Patrick Figel via dev-security-policy]

On 13/02/2017 16:15, Jürgen Brauckmann via dev-security-policy wrote:
> Gervase Markham via dev-security-policy schrieb:
>> 1) As with all CAs, update all their domain validation code to use one
>> of the 10 approved methods;
> 
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
> only 4 methods per Ballot 181?

My understanding is that while Ballot 181 included only those methods
from Ballot 169 that were not affected by any patent exclusion notices,
plus "any other method", Mozilla will disallow "any other method" and
instead ask CAs to limit their validation methods to the ones from
Ballot 169.

This approach would still be compliant with the BRs because the 6
methods affected by the patent exclusions can be counted as
implementations of "any other method".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Misissuance Action Items

[Nick Lamb via dev-security-policy]

On Monday, 13 February 2017 15:15:47 UTC, Jürgen Brauckmann  wrote:
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
> only 4 methods per Ballot 181?
> 
> Jürgen

Ballot 169 identified exactly 10 methods. Although this ballot passed 
unanimously, meaning that both CA members and Browser members on the whole 
supported these 10 methods, subsequently the CA/B effectively undid the changes 
from Ballot 169 because of patent concerns.

Mozilla's position as I understand it is that regardless of what happens with 
patents, they don't want CAs to continue inventing their own ad hoc validation 
methods (witness the flaws in the method GoDaddy came up with). Thus, even 
though some of the methods from Ballot 169 are not included in the Baseline 
Requirements today, Mozilla intends to oblige root programme members to pick 
from those ten methods.

So far as I can see three factors might cause a CA to decide it's necessary in 
their opinion to reject any particular method. These are

1. The method isn't allowed for them under the BRs, or another root programmes 
rules.

2. The method is subject to patent or other legal rights and they're unable or 
unwilling to agree acceptable terms to use the method.

3. The method is incompatible with the CA's business model or doesn't meet 
their own standards for validation.


For (1) I believe the BRs currently allow all ten Ballot 169 methods because 
they have an "any method" escape clause. If a CA believes another root 
programme requirement conflicts this would be the right forum for the CA to 
tell Mozilla about it.

For (2) where a CA is aware of such rights and they weren't already revealed to 
the CA/B it'd sure be helpful to know about them here.

For (3) I don't see any problem unless the CA rules out all ten methods. If any 
CA is on the verge of doing that they should definitely reach out to us in 
m.d.s.policy to explain their thinking.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Intermediates Supporting Many EE Certs

[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: Monday, February 13, 2017 7:23 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Intermediates Supporting Many EE Certs
>
>
> What can be done about the potential future issue (which might happen with
> any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.
>
> Gerv
>

Either timespan or total certificates issued limits, as ballots, accounting for 
quantity growth from the end entity certificate lifespan reduction proposals, 
would be an approach.

Getting all user agents with interest is issuance limits to implement the CA 
Issuers form of AIA for dynamic path discovery and educating server operators 
to get out of the practice of static chain installation on servers would make 
CA rollovers fairly fluid and less subject to operator error of failing to 
install the proper intermediate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Peter Bowen via dev-security-policy]

On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via
dev-security-policy  wrote:
> On 10/02/17 12:40, Inigo Barreira wrote:
>> I see many "should" in this link. Basically those indicating "should notify
>> Mozilla" and "should follow the physical relocation section".
>
> It may be that this document does need redoing in formal policy
> language. In the mean time, anyone uncertain about its meaning should
> ask Kathleen.

Gerv,

In addition to updating it to follow formal policy language, I would
suggest adding it directly to the policy.  As it stands today there
are 79 pages in the wiki starting with "CA:".  It simply isn't
possible to know which ones are effectively part of the policy and
which are other random things.  I realize building and maintaining
long policies is time consuming, but it is important to be clear.  CAs
are routinely called out for unclear or incomplete CPs and CPSes, so I
think it is fair to ask Browsers to have clear and complete trust
store policies.

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

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Inigo Barreira via dev-security-policy]

Yes, I know what happened but it´s not what the document says. Unless there´s 
another document, it seems to me that you haven´t acted according to what this 
page says. If I understand correcly, a should is a conditional and then it´s 
not a requirement. Furthermore there´s no indication on the consequences if you 
don´t do it, at least in this document. Maybe I´m missing some others, for 
sure, but i´d like to have the full picture.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: lunes, 13 de febrero de 2017 13:15
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Public disclosure of root ownership transfers (was: Re: Google 
Trust Services roots)

Hi Inigo.

On 10/02/17 12:40, Inigo Barreira wrote:
> I see many "should" in this link. Basically those indicating "should 
> notify Mozilla" and "should follow the physical relocation section".

It may be that this document does need redoing in formal policy language. In 
the mean time, anyone uncertain about its meaning should ask Kathleen.

> What does it happen if you don´t notify Mozilla?

Well, this was a factor in our dis-trust of WoSign and StartCom, so I guess the 
answer is "we take it seriously" :-)

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

Re: GoDaddy Misissuance Action Items

[Jürgen Brauckmann via dev-security-policy]

Gervase Markham via dev-security-policy schrieb:
> 1) As with all CAs, update all their domain validation code to use one
> of the 10 approved methods;

I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
only 4 methods per Ballot 181?

Jürgen
___
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 via dev-security-policy]

Hi Steve,

On 12/02/17 15:27, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8836487

Thank you for this timely response. Mozilla continues to expect answers
to all reasonable and polite questions posed in our forum, and is happy
that Symantec is taking this approach.

Here are some additional questions, although Mozilla as always reserves
the right to ask more later. Some of my questions may be similar to
those posed by other group participants.

* What criteria are Symantec using to judge whether the validation of a
particular certificate was deficient and needs redoing? Does this
process rely on an assumption that any work logs kept by the RAs are
accurate records of work actually done?

* When you say "Symantec authorized CrossCert to issue certificates from
each of the identified CAs", do you mean all five separate certificates
listed to the left of this answer in the document? Or do you mean the
top list? Or the bottom list? Or something else?

* When the revalidation process is complete, will Symantec be reporting
on how many certificates were unable to be revalidated?

* Further to your third response, can you provide a list of the
certificate fields which CrossCert did or did not have control over, and
whether those fields had Symantec-side validation with compliance
flagging, and whether those flags could be overridden? To show what I am
after, such a list might hypothetically begin:

- notBefore/notAfter: no direct control
- Certificate duration: control, minimum 12 months, maximum 39 months
- Hash algorithm: no control
- Domain name: full control, Symantec-side validation, overrideable


* You write: "Further, we have deployed support for, and honor
Certification Authority Authorization across all systems to put control
of authorized CA’s in the hands of customers". This is great news :-)
From what date has this been true? Can you confirm that CAA checking
applies to all Symantec-owned brands?

* Further to your answer about sampling sizes, what (in Symantec's
experience) normally defines the sample size an auditor will use when
sampling issued certificates during an audit? Is it a fixed number, or
defined by the auditor, the issuer, or a dialogue between the two, or
some other method?

* http://vtn.certisign.com.br/repositorio/politicas/DPC_da_Cert
isign.pdf is dated 2012. BRs section 2 say that the CP and CPS need to
be annually updated. Do we understand that this did not happen in the
case of Certisign?

* Same question for CrossCert.

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

Intermediates Supporting Many EE Certs

[Gervase Markham via dev-security-policy]

The GoDaddy situation raises an additional issue.

Mozilla is neither adding any of the 8951 revoked certificates to
OneCRL, nor untrusting any GoDaddy intermediates. However, a more
serious incident might have led us to consider that course of action. In
that regard, the following information is worth considering.

The certificates in the GoDaddy case chain up to two different
intermediates:

GoDaddy Secure Certificate Authority - G2 : 6563
Starfield Secure Certificate Authority - G2 : 2388

Those two intermediates together support over a million certificates,
with a roughly 90/10 split between GoDaddy and Starfield. GoDaddy does
not have a rotation policy for intermediates. Un-trusting such
intermediates from the current date onwards is possible; un-trusting
them from a date in the past would be extremely impactful to sites.
Using this particular problem as an example, it occurred between July
2016 and January 2017. If we wanted to untrust these intermediates from
July 2016 onwards, that would affect (by my rough guess) around 300,000
certificates. (The actual figure will depend upon the lifetime
distribution histogram.) Contacting that many customers and getting them
to rotate their certs would be a gargantuan effort.

What can be done about the potential future issue (which might happen
with any large CA) of the need to untrust a popular intermediate?
Suggestions welcome.

Gerv

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

GoDaddy Misissuance Action Items

[Gervase Markham via dev-security-policy]

As members of the group will be aware, last month GoDaddy filed an
incident report concerning a problem with their domain validation system.

Domain validation is the most important task a CA can undertake, any any
flaws in it are serious. This is why the CAB Forum has been working for
some time on carefully documenting best practice in domain validation,
and passed ballot 169 to incorporate them into the Baseline
Requirements. The problem experienced by GoDaddy is one explicitly
foreseen by the drafters of those best-practice validation methods.

That is why, despite some IPR-related tangles, Mozilla will be requiring
in its next CA Communication that all CAs move to using only those
documented methods in a fairly short timeframe, regardless of what the
BRs say. CAs may wish to not wait for that communication to arrive
before starting to adapt their systems.

We note that GoDaddy's response to this issue was delayed because it was
not submitted through their expected channels. We will be working in the
CAB Forum to get the CAB Forum to host a master list of CA security
contacts, open both to CAs who are and are not members of the Forum, to
try and reduce the likelihood of this happening in future.

We asked GoDaddy for a list of domains where they revoked the cert
because they could not re-do the validation, and compared them to the
Alexa top 1M domains. There were no hits in the top 10,000, and only 15
in the top 100,000. As attackers tend to target popular domains, we feel
it is _unlikely_ that any certs ended up in the wrong hands as a result
of this problem. So we do not plan to add any of the 8951 certs to OneCRL.

Here is our proposed remediation plan for GoDaddy.

1) As with all CAs, update all their domain validation code to use one
of the 10 approved methods;

2) Implement comprehensive automated testing for their domain validation
code for all issuance systems;

3) Make sure those tests automatically run when any change is made to
the code, before deployment, such that deployment is gated on a pass;

4) Get a statement from their auditors that these tests have been
created and positioned correctly in the deployment workflow.

All steps to be completed within 3 months.

Comments on this plan are welcome, including from GoDaddy.

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

[Kurt Roeckx via dev-security-policy]

So after reading this, the following auditors aren't trusted by Symantec 
anymore:

- E Korea
- E Brazil

The following isn't trusted by Mozilla anymore:
- E Hong Kong

This seems to be a worrying trend to me.


Kurt

On 2017-02-12 20:25, Eric Mill wrote:

Also relevant are Symantec's statements about two E regional auditors.

One section describes contradictions from E KR (Korea) in describing why
some CrossCert issuing CAs were not in scope:

• The list of CAs in the audit was produced by CrossCert and given to E
KR as the scope to audit. It was not given to E by Symantec.

• E KR initially stated that CrossCert did not fully disclose the list of
CAs. E KR later stated that CrossCert provided a list of all their
issuing CAs but reduced the list of issuing CAs in scope of sampling for
budgetary reasons.

• Due to these conflicting statements and further discoveries explained
below, Symantec will no longer accept audits from E KR.


And a second section is about contradictions and delays in describing the
scope of an audit that E BR (Brazil) performed on Certisign:

E BR produced two deficient letters regarding the 2014 and 2015 Certisign
audits. Initially we received a letter that stated a January 1, 2014 to
December 31, 2014 audit period in its introduction and a January 1, 2014 to
December 31, 2015 audit period in its conclusion. The letter appeared to
cover a two year period. We asked for clarification multiple times. That
clarifying letter stated a 2015 audit period.

E BR does not meet our requirements for RA audit quality, timeliness, and
responsiveness to our demands. Symantec will no longer accept audits from
E BR should we have a future need for in-market audit support.




On Sun, Feb 12, 2017 at 2:11 PM, Eric Mill  wrote:


Though Nick's email implies the announcement, for the benefit of the list,
here's Symantec's introduction at the top of their response:

Based on our investigation of CrossCert, we have concerns due to (1)
demonstrated non-compliance with processes and controls, (2) assertions of
third party auditors that need far greater oversight than we previously
expected, and (3) the fact that these issues have enabled cases of
certificate mis-issuance. As a result, we have made the decision to
terminate our partner RA program.

We will continue to work with select partners that have local market
contacts and expertise to facilitate an interface with customers and
collection of relevant documentation, however Symantec personnel will
validate 100% of all asserted identity data and control certificate
issuance going forward. We have communicated this change to each of our RA
partners, we are finalizing a transition plan, and intend to implement that
transition quickly.

In addition, to alleviate any concern by customers or relying parties on
the integrity of the certificates issued by these RA partners, Symantec
will review the validation work of 100% of issued certificates and
revalidate any where we identify any deficiency. Certificates issued with
deficient validation will be replaced and revoked. Our work will be
included in scope of our next WebTrust audits.


On Sun, Feb 12, 2017 at 1:02 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin  wrote:

A response is now available in Bugzilla 1334377 and directly at:
https://bugzilla.mozilla.org/attachment.cgi?id=8836487


Thanks for these responses Steve,

I believe that Symantec's decision to terminate the RA Partner programme
was a good one, not only in light of what's been found during this specific
investigation, but also because it makes the CA function within Symantec
simpler. It definitely feels as though some of the issues (big and small)
with Symantec's CA function in the past few years grew out of complexity.
Simpler systems are easier to correctly reason about and thus to manage
properly.

Simpler systems are also easier for the Root Programmes to oversee and
for the Relying Parties to put their trust in. This group has fought
against the presumption that "foreign" CAs are necessarily less
trustworthy, but the fact is that a person who was happy with a Symantec
certificate on the basis that it was issued by a famous US Corporation
might have been very surprised to learn the decision to issue was actually
taken by a company they've never heard of in Korea, or Brazil.

Given Symantec's experiences here, I would recommend that Mozilla's
routine letter to CAs might ask them if they have any similar programme and
if so what measures they have in place to ensure their RAs or similar Third
Parties are really living up to the standards Mozilla requires. Depending
on the responses this might need further action from Mozilla. It would also
make sense to ask about this during new CA enrollment. There's maybe a
small piece of work here to figure out what sort of characteristics best
distinguish something like Symantec's