Re: Certificate for com and it

[Gervase Markham via dev-security-policy]

On 08/02/18 13:47, Hanno Böck wrote:
> Is a revoked intermediate cert a license for operating a yolo CA that
> signs everything? Given the fragility of revocation checking I'd find
> that a problematic precedent.

In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.

> The OCSP seems operational and replies with "Good" and the issuance
> happened before it's being added to OneCRL.

If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...

> I don't find a reference why this intermediate had been added to
> OneCRL, but I think this deserves more clarification what's going on
> here.

OneCRL additions normally have an associated bug but I can't see one for
this...

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

Re: Misissuance/non-compliance remediation timelines

[Gervase Markham via dev-security-policy]

On 07/02/18 15:14, Alex Gaynor wrote:
> That said, given the issues Paul highlighted in his original mail (which I
> wholeheartedly concur with), it seems the place to focus is the folks who
> are getting Ds right now. Therefore I think the essential part of your
> email is your agreement that CAs which are persistently low performing need
> to be recognized and potentially penalized for the sum total of their
> behaviors.

This is, in a reasonably strong sense, what happens now. We require each
incident in which a CA is involved to be documented in a public bug, so
all can see the timeline, outcomes, how the CA reacted and other factors
which might be taken into account when determining a CA's competence.

Occasionally, we decide that some CA's list of recent[0] problems is
sufficiently serious[0] that we need to run an investigation. We do so,
and invite the CA to more formally comment on the sum total of the
problems. We assess the responses and the style and level of response,
and make a determination[0]. This is what happened to WoSign, Symantec
and PROCERT:
https://wiki.mozilla.org/CA:WoSign_Issues
https://wiki.mozilla.org/CA:Symantec_Issues
https://wiki.mozilla.org/CA:PROCERT_Issues

I therefore expect and hope that CAs in our program have noted what
happened in those cases, particularly PROCERT (which is probably the
clearest case of simple "general incompetence" that we have had), and
want to make sure they are not next.

Gerv


[0] Yes, this is vague. But so is the concept of "trust".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ccadb.org

[Gervase Markham via dev-security-policy]

On 30/01/18 00:48, James Burton wrote:
> I was doing research on the ccadb.org site and was surprised to find that
> the site is running only in HTTP and is not using HTTPS. Now, I understand
> that GitHub pages don't support HTTPS for custom domains but you could
> always use CloudFlare for HTTPS support in the meantime until GitHub
> enables HTTPS for custom domains.

The Cloudflare solution turns out not to be ideal for Mozilla IT. They
have instead proposed another solution using AWS and Nubis, which is
being implemented in the (infrastructure-confidential) bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 . I've pinged the
bug so hopefully something should happen soon.

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

Re: Summary of Responses to the November CA Communication

[Gervase Markham via dev-security-policy]

On 24/01/18 21:41, Wayne Thayer wrote:
> First off, I question if we would really use lesser sanctions more often. I
> think we would still want to coordinate their implementation with other
> user agents, and that is a tedious process.

I think it's important for root programs to make independent decisions,
therefore I would be uneasy about too high a level of coordination with
regard to CA sanctions.

Once two root programs have both decided to take similar action, it is
reasonable to coordinate to make sure the impact of the two requirements
is not disproportionate compared to the impact each individual root
program is attemping to have. But that's different from saying: "We are
going to sanction CA Foo - are you in?", or even "We'll sanction CA Foo
if you do."

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

Re: Summary of Responses to the November CA Communication

[Gervase Markham via dev-security-policy]

On 24/01/18 13:56, Ryan Sleevi wrote:
>> more frequently when requirements change. I propose that we require CAs to
>> update their CPS to comply with version 2.5 of the Mozilla root store
>> policy no later than 15-April 2018.

I think Ryan is right here; the deadline for complying with most of the
new changes was "immediately" - in part, that was due to the nature of
the changes, in that this was possible, and also we put out a call for
"does anyone need an implementation period for any of these things", and
the only response was from Globalsign, which led to the modification of
the email intermediate compliance dates.

I realise that updating one's CPS to match changes in practice can't be
done overnight - there are change control procedures - but taking 15
months is ridiculous. We should get back to Microsec and tell them that
this is unacceptable. If we do set a "new" deadline for CPS updates, it
should be closer than mid-April, and we should update our policy to make
it clear how fast we expect CPSes to be updated in the wake of
"immediate" new requirements - either from a new version of the policy,
or from some emergency action we take.

> 2 should be inconsequential, but 1 has a very real effect - unless/until
> the CA updates their CP/CPS to explicitly state what methods they are using
> (implicitly disavowing the 'any other method'), then a CA can receive a
> fully compliant audit, despite actively issuing certificates using 'any
> other method', in contravention of Mozilla Policy.

Ryan: I thought you had previously made the case that all CAs actually
had to abide by the latest version of the BRs? If that is so, then
surely your point above is incorrect?

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

Re: DRAFT January 2018 CA Communication

[Gervase Markham via dev-security-policy]

On 24/01/18 22:19, Jonathan Rudenberg wrote:
> While these CAs might want six months, it’s not clear that a good
> argument has been made for this. Let’s Encrypt stopped validating
> using the TLS-SNI-01 method under two hours after learning that there
> was a *potential* security vulnerability in the validation method.
> Why should we expect any less from other CAs? We should err on the
> side of protecting users, not CAs using insecure validation methods
> that don’t even stand up to a small amount of adversarial scrutiny.

Six months may or many not be the right timeline, but I don't think it's
fair to compare removing an option in an automated process (which was,
in fact, subsequently restored for existing customers within a few days)
with retraining all your validation specialists to use a different
manual process. Such work cannot be done in 2 hours.

Gerv

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

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

On 24/01/18 18:02, Doug Beattie wrote:
> Can we consider this case closed with the action that the VWG will
> propose a ballot that addresses pre and postdating certificates?

Yes. I don't believe anyone has suggested that Globalsign broke a formal
rule, either in the BRs or Mozilla's requirements. Thank you for
engaging with us on this topic.

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

Re: Summary of Responses to the November CA Communication

[Gervase Markham via dev-security-policy]

On 24/01/18 16:44, Wayne Thayer wrote:
> In the past, new policy versions have not had a clearly defined future
> effective date. That seems to have led some CAs to interpret the timing for
> making changes to be "whenever we get around to it" instead of the intent
> of "the policy is effective immediately and we expect you to comply with it
> as soon as possible". Given this abuse, I'd prefer to put a date on each
> new version of the policy by which CAs are expected to comply with it. This
> date would be 2-3 months after the policy was announced, but would also
> allow specific carve-outs for changes that take longer.

We do actually do that, it's just not written in the policy itself. See:
https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
which gives all the publication dates and compliance dates.

Gerv

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

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

Hi Doug,

Thanks for the quick response.

On 24/01/18 11:52, Doug Beattie wrote:
> In the case below, the customer ordered a 39 month certificate and
> set the notBefore date for 2 months into the future.

Momentary 2017/2018 confusion in my brain had me thinking that this was
further into the future than it actually was. But yet still, it is the
other side of a reduction in certificate lifetime deadline.

> We permit customers to set a notBefore date into the future, possibly
> for the reason listed below, but there could be other reasons.

So if a customer came to you today and renewed their certificate for
www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
(perfectly fine), and then requested a second 39-month certificate valid
from 24th Apr 2020 to 24th July 2023, would you issue this second one?

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

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

On 24/01/18 04:57, David E. Ross wrote:
> I am not sure about prohibiting forward-dating the notBefore date.  I
> can picture a situation where an existing site certificate is going to
> expire.  The site's administration decides to obtain a new certificate
> from a different certification authority.  Because of various
> administrative processes, the switch to the new site certificate cannot
> be accomplished quickly (e.g., moving the server); so they establish a
> notBefore date that is a month in the future.

Why would that be _necessary_? What would go wrong if the cert was cut
with a notBefore of the current date, apart from the fact that they'd
need to renew it a month earlier?

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

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

Hi Jonathan,

On 23/01/18 22:55, Jonathan Rudenberg wrote:
> A certificate issued by GlobalSign showed up in CT today with a notBefore 
> date of March 21, 2018 and a notAfter date of April 23, 2021, a validity 
> period of ~1129 days (more than three years).

Thank you for pointing this out. This does seem at first look like an
attempted end-run around the 825-day validity period restriction which
comes into effect soon. Perhaps GlobalSign would care to comment here?
If not, I can file a bug and make a formal request.

> 1) The Root Store Policy should explicitly ban forward and back-dating the 
> notBefore date.

I am not opposed to this, but I would want to allow CAs to make
representations about when this is necessary so we can see if any
exceptions do actually need to be made. But a general rule might be a
good idea.

> 2) Firefox should implement a technical check to enforce the validity period 
> so that issuance practices like this do not impact users (see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Does Chrome already do this? If so, I might expect this cert, once it
becomes valid, not to work in Chrome...

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

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 19/01/18 13:20, Jakob Bohm wrote:
> My suggestions are only meant to inspire formal rules written / chosen
> by module leaders such as you.

But the entire point of this discussion is that we are pointing out it's
hard to make such rules in the way you have just made them without being
arbitrary, and arbitrariness is something we want to avoid. So giving us
an example arbitrary ruleset is not really moving the discussion forward
much.

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

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 19/01/18 01:05, Jakob Bohm wrote:
> On 18/01/2018 11:01, Gervase Markham wrote:
>> On 17/01/18 19:49, Jakob Bohm wrote:
>>> 3. Major vertical CAs for high value business categories that issue
>>>    publicly trusted certificates at better than EV level integrity.  For
>>
>> How do you define "major"? And "high value business category"?
> 
> Major would be the biggest 1 to 3 of their kind, ignoring any covering
> only a small fraction of the relevant web site/e-mail population even if
> in the top 3.  Also any not doing this globally is not major.

I guess my question was ambiguous. Clearly it's very easy to come up
with arbitrary definitions for these things, but what's the rationale?
Why 1-3? Why not 1-8?

> High value business category would be a category where web users have an
> extremely high need for genuineness.  Banks/central payment systems
> would be the canonical example, with the VISA CA/SET combination as a
> possible historic example (noting that it looks like they don't
> currently qualify even if they did in the past).

You've just shifted the definitional problem to the words "extremely
high need for genuineness".

Proving examples of what you personally mean by these terms is not
sufficient to make a definition, unless the Mozilla policy becomes
"whatever Jakob Bohm decides".

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 18/01/18 14:24, Ryan Sleevi wrote:
> Or, conversely, that we cannot discuss inclusion policies in isolation from
> discussion root policies - we cannot simultaneously work to strengthen
> inclusion without acknowledging the elephant in the room of the extant CAs.

We aren't necessarily "strengthening" inclusion, in the sense of making
it harder to get in - the outcome of the discussion could be a loosening.

If we come up with new inclusion criteria and some existing CAs do not
meet them, we would need to have a separate discussion to decide what to
do, with the main options being grandfathering them in, restricting them
in some way, or removing them.

> Isn't this effectively the VISA situation? When were their first audits -
> late 2016 / early 2017?

I'm not certain; I'll ask Kathleen.

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

Hi Ryan,

On 18/01/18 13:55, Ryan Sleevi wrote:
> I do want to point out that you are substantially changing the goals from
> what Wayne posited. That is, you have moved the goalpost from being
> 'objective' to being what is 'fair', and 'fair' will inherently be a
> subjective evaluation.

One of my goals in this discussion is to record some of the thoughts I
had on the topic, of which this is one. Those thoughts are far from
unchallengeable - as you have recognised, since you are challenging one
of them :-)

> Was it your intent to redefine the problem like that? If not, do you have
> those concerns about the objective measures, or is your goal to find
> objective measures which you subjectively believe to be 'fair'? For
> example, an objective measure would be "Paid for a 2-week vacation for
> Gervase Markham and family every year to a location of their choosing", but
> I suspect that you might argue it's subjectively 'not fair'?

If every CA had to do it, it would both be an objective measure and
subjectively fair. (Although one could argue it was unfair if I asked
one CA to send us to Bogor Regis and another to send us to the Maldives.
it would also mean a maximum of 26 CAs in the program at one time, and
in the past we have decided against a hard numerical limit.)

I would like to find a set of objective measures which the group
considers as a whole to be "fair", in that the objective measures do not
use criteria which are irrelevant to operating as a CA (such as buying
my family a holiday). This may not be possible, of course - we will see
- but that doesn't stop me wanting it.

Gerv

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 18/01/18 13:53, Ryan Sleevi wrote:
> But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at
> the detriment to both user security and the ecosystem. If your goal is for
> policies that do not favor incumbents, then it seems a significantly
> different discussion should happen - and proposals such as Jonathan's
> inherently provide a way to normalize that field.

If Jonathan's proposal were applied to all CAs, it might well reduce
incumbent advantage. But that would be a different discussion from
inclusion criteria. If it were applied only to new CAs, it would be
relevant to the current discussion - but then it would entrench
incumbent advantage.

> A prime example, recently highlighted in ongoing CA inclusion discussions,
> is whether or not a CA must have an unbroken series of audits since their
> key was created (the PITRA). 

Yes. It seems that we have come to the position that it does not
necessarily have to. But I would raise an eyebrow at a root that had
been operating for 10 years and had only got its first set of audits
last week.

> Obviously, during the introduction of the
> Baseline Requirements, this was not the case for any incumbents - and
> Mozilla further granted an effective 3 years for incumbents beyond the BRs
> effective date to come up to date, while simultaneously examining new CAs
> against the modernized criteria. 

I'm not sure it was that long, and even if it was, I think this
criticism is a little harsh given that we have been at the forefront of
giving the BRs any teeth at all.

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

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 17/01/18 19:49, Jakob Bohm wrote:
> 3. Major vertical CAs for high value business categories that issue
>   publicly trusted certificates at better than EV level integrity.  For

How do you define "major"? And "high value business category"?

> 4. Selected company CAs for a handful of too-bit-to-ignore companies
>   that refuse to use a true public CA.

So you think Mozilla's policy should include formal acknowledgement that
some companies are too big to ignore?

How do you decide which companies are in this category?

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 19:14, Ryan Hurst wrote:
> Since Google's PKI was mentioned as an example, I can publicly state
> that the plan is for Google to utilize the Google Trust Services
> infrastructure to satisfy its SSL certificate needs. While I can not
> announce specific product roadmaps I can say that this includes the
> issuance of certificates for Google offerings involving hosting of
> products and services for customers.

This is an interesting situation because it points to an interesting
ramification of a requirement which is anything like "issues certs to
the public".

We can compare large companies who happen to be in the cloud hosting
business (e.g. Google, Amazon, Microsoft) with those that are not. The
former category can pass a "issuing certs to the public" test and so
qualify for inclusion, and can then use that same infra to issue their
internal certs, or certs for their own public-facing domains and
hostnames. A large company which happens not to be in the cloud hosting
business cannot pass that test, and so has to use a 3rd party CA for
their cert requirements.

One could argue that deciding whether a large tech company gets the
convenience of a self-hosted root based on whether they provide a
particular service is not very fair.

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 15:41, Peter Bowen wrote:
> In the interest of transparency, I would like to add one more example
> to your list:
> 
> * Amazon Trust Services is a current program member.  Amazon applied
> independently but then subsequently bought a root from Go Daddy
> (obvious disclosure: Wayne was VP at Go Daddy at the time).  So far
> there is no public path to bring Amazon a public key/CSR you generate
> on you own server and have Amazon issue a certificate containing that
> public key.  The primary path to getting a certificate issued by
> Amazon is to use AWS Certificate Manager.  That being said, we have
> issued certificates to hundreds of thousands of domains and Mozilla
> telemetry data shows they are being widely used by users of Mozilla
> software products.

IOW, you can't bring your CSR to Amazon and get a certificate, but you
can bring your _domain_ to Amazon and get a certificate.

Gerv

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 15:13, Jonathan Rudenberg wrote:
> I like this concept a lot. Some concrete ideas in this space:
> 
> - Limit the validity period of root certificates to a few years, so that the 
> criteria can be re-evaluated, updated, and re-applied on a rolling basis.

Are you saying we should do this for new entrants only? If so, surely
that would give existing CAs a significant competitive advantage? Or, if
not, what is the relevance of your point to the question under
consideration?

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should
focus less on the questions of whether a CA
> is "appropriate" or "deserving" of participation in the Mozilla Root
> Program, and more on whether they are willing and able to fulfill the
> expectations of them as a steward of global trust on the internet. 

If you ask any applicant "are you willing and able to fulfil what is
expected of you as a steward of global trust on the Internet?", and they
know they have to say "Yes" to get in, they will say "Yes". So is the
upshot of your position that anyone who wants to apply can get in?

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

Re: CCADB disclosure of id-kp-emailProtection intermediates

[Gervase Markham via dev-security-policy]

On 17/01/18 10:25, Rob Stradling wrote:
> However, the Stable version of the Mozilla Root Store Policy [2] still
> says 15th January 2018.
> 
> Surely the Stable version of the Policy is in force and the Draft
> version is not yet in force?
> 
> Perhaps Mozilla could consider publishing a v2.5.1 of the Policy that
> (compared to v2.5) simply updates this disclosure deadline?

We published an erratum, and have noted in every discussion of this
issue that the dates have changed.
https://wiki.mozilla.org/CA/Root_Store_Policy_Archive

Perhaps we should have done a 2.5.1 but at the time I thought telling
everyone would be sufficient.

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Gervase Markham via dev-security-policy]

On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote:
> We discussed a similar approach (using CAA) on our community forum,
> and concluded we don't want to pursue it at this time:
> https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT
> record would probably work more widely than CAA, but it would still
> be encouraging further integration with TLS-SNI-01, when we really
> want to encourage migration away from it. Right now it's our feeling
> that the account and renewal whitelisting should mitigate most of the
> pain of migrating away, but experience and feedback from subscribers
> will help inform that over time.

Why would you want to continue migrating away if it were based on a
self-serve whitelist? Would that not re-secure the method?

Gerv

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Gervase Markham via dev-security-policy]

On 12/01/18 14:52, Doug Beattie wrote:
> For shared IP address environments, it may be possible to receive a
> certificate for a domain you don’t actually control, but a number of
> things need to happen in order for this to be successful.  What can
> go wrong?

Doug: what do you see as the exact differences between your setup and
the TLS-SNI-01 configuration? It seems to me that both are vulnerable in
the same circumstances (i.e., hosting provider has many users hosted on
the same IP address, and users have the ability to upload certificates
for arbitrary names without proving domain control).

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Gervase Markham via dev-security-policy]

On 10/01/18 17:39, Matthew Hardeman wrote:
> Here again, I think we have a problem.  It's regarded as normal and
> acceptable at many web host infrastructures to pre-stage sites for
> domain-labels not yet in use to allow for development and test deployment.

I agree that "no unknown domain names" is hard to implement "No domain
names owned by another customer" is easier and doesn't cause the
problems you raise. "No acme.invalid" is even easier.

> In the course of adopting the 10 blessed methods, did any of the methods
> move forward with the expectation that active effort on the part of non-CA
> participants versus the status quo would be required in order to ensure the
> continuing reliability of the method?

"Active effort vs. the status quo" is a skewed framing because security
always requires active effort in the face of change, new entrants etc. A
new entrant in the email market has to make an active effort to make
sure that the special addresses are not claimable, even though that
issue has been known for years.

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Gervase Markham via dev-security-policy]

On 10/01/18 17:04, Matthew Hardeman wrote:
> That seems remarkably deficient.  No other validation mechanism which is
> accepted by the community relies upon specific preventative behavior by any
> number of random hosting companies on the internet.

I don't think that's true. If your hosting provider allows other sites
to respond to HTTP requests for your domain, there's a similar
vulnerability in the HTTP-01 checker. One configuration where this can
happen is when multiple sites share an IP but only one gets port 443
(i.e. the pre-SNI support situation), and it's not you.

Or, if an email provider allows people to claim any of the special email
addresses, there's a similar vulnerability in email-based methods.

The "don't allow acme.invalid" mitigation is the easiest one to
implement, but another perfectly good one would be "don't allow people
to deploy certs for sites they don't own or control", or even "don't
allow people to deploy certs for sites your other customers own or
control". Put that way, that doesn't seem like an unreasonable
requirement, does it?

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Gervase Markham via dev-security-policy]

On 10/01/18 14:34, Jakob Bohm wrote:
> Enforcement on shared hosting systems would be easier if the TLS-SNI-01
> ACME mechanism used names such as
>   1234556-24356476._acme.requested.domain.example.com
> since that would allow hosting providers to restrict certificate uploads
> that claim to be for other customers domains.  

Hosting providers can simply refuse to accept uploads of any certificate
which contains names ending in "acme.invalid".

AIUI, this is Let's Encrypt's recommended mitigation method.

Gerv

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

Re: Changes to CA Program - Q1 2018

[Gervase Markham via dev-security-policy]

On 10/01/18 00:23, Kathleen Wilson wrote:
> I would like to thank Aaron Wu for all of his help on our CA Program,
> and am sorry to say that his last day at Mozilla will be January 12. I
> have appreciated all of Aaron’s work, and it has been a pleasure to work
> with him.

Seconded.

> I think this is a good time for us to make some changes to Mozilla’s
> Root Inclusion Process to improve the effectiveness of the public
> discussion phase by performing the detailed CP/CPS review prior to the
> public discussion. The goal of this change is to focus the discussion
> period on gathering community input and to allow the process to continue
> when no objections are raised.

This seems fine to me.

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

Re: Potential problem with ACME TLS-SNI-01 validation

[Gervase Markham via dev-security-policy]

On 10/01/18 02:26, j...@letsencrypt.org wrote:
> We've received a credible report of a problem with ACME TLS-SNI-01 validation 
> which could allow people to get certificates they should not be able to get. 
> While we investigate further we have disabled tls-sni-01 validation.
> 
> We'll post more information soon.

https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996

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

Re: Serial number length

[Gervase Markham via dev-security-policy]

Hi,

On 29/12/17 06:24, Jakob Bohm wrote:
> 1. Do all recently issued certificates have to contain at least 64 bits
>   of randomness in their serial numbers?

Yes. (References given by others.)

> 2. Is it acceptable for a CA to satisfy this requirement by generating
>   random 64 bit serial numbers and checking if there is a certificate
>   with that random serial before using it?

IMO Yes. The requirement is specifically to include 64 bits of output
from a CSPRNG. Bits don't stop being from a CSPRNG just because they've
compared unequally with a list of other sets of bits.

> 3. Or would the elimination in #2 reduce the entropy of such serial
>   numbers to slightly less than 64 bits (since there are less than 2**64
>   allowed values for all but the first such certificate)?

Technically, it would, but I don't think that's a problem as the
requirement is written, and I don't think it's a problem in practice
because the entropy reduction is so slight and the error margin is
intentionally large.

2^64 is 18,446,744,073,709,552,000. Even if you issue a billion
certificates, the entropy reduction is 0.001%. (May be off by an
order of mag. or two, but roughly that.)

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

Re: Dashboard and Study on CAA Adoption

[Gervase Markham via dev-security-policy]

Hi Quirin,

On 15/12/17 15:09, Quirin Scheitle wrote:
> The results, paper, and a dashboard tracking CAA adoption are available under 
> 
> https://caastudy.github.io/

Belatedly, thank you and your colleagues for doing this excellent work.

It is interesting that you have received no iodef messages at all. I can
imagine CAs deprioritizing that work in favour of getting their
implementations right. I can see a time, when CAA implementations have
settled down and are reliable, that we might look at mandatory reporting
of attempted misissuance.

CAs are already able to use CA-specific tags to restrict particular
validation methods and certificate types; this is something I think it's
reasonable to let the market provide if there is demand.

The DNS operator privilege is there because it doesn't make too much
sense for an organization to ask itself for permission to issue.

I would expect CAs to be storing the results of their CAA lookups in
their issuance logs, in sufficient detail for them to be checked later,
even if they are not published.

I share your hope that the deployment and use of CAA, and the accuracy
and consistency of checking, will improve in the days ahead. It will be
fascinating if you are able to repeat this research in six or twelve
months time.

One other quote:

"For 1 domain, our scans showed a CAA configuration that
consistently did not permit any CA to issue, yet a certificate
was issued during this time. Upon inquiry, the domain name
holder confirmed that they had fully automated their certifi-
cate issuance process, including automatic reconfiguration of
CAA records for a brief time period."

That's pretty awesome :-)

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

Mozilla CA Team availability

[Gervase Markham via dev-security-policy]

The Mozilla CA team will have limited availability over the Christmas
and New Year period, and so you should not expect us to engage
substantively in complex debates, make controversial decisions, or
otherwise act as if we were functioning at full strength :-)

We hope that normal service will be resumed in mid-January.

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

Re: CA generated keys

[Gervase Markham via dev-security-policy]

On 15/12/17 16:02, Ryan Hurst wrote:
> So I have read this thread in its entirety now and I think it makes sense for 
> it to reset to first principles, specifically:
> 
> What are the technological and business goals trying to be achieved,
> What are the requirements derived from those goals,
> What are the negative consequences of those goals.
> 
> My feeling is there is simply an abstract desire to allow for the CA, on 
> behalf of the subject, to generate the keys but we have not sufficiently 
> articulated a business case for this.

I think I'm in exactly this position also; thank you for articulating
it. One might also add:

* What are the inevitable technical consequences of a scheme which meets
these goals? (E.g. "use of PKCS#12 for key transport" might be one
answer to that question.)

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

Re: On the value of EV

[Gervase Markham via dev-security-policy]

On 13/12/17 11:58, Tim Shirley wrote:
> So many of the arguments made here, such as this one, as well as the recent 
> demonstrations that helped start this thread, focus on edge cases.  And while 
> those are certainly valuable to consider, they obscure the fact that “Green 
> Bar” adds value in the mainstream use cases.  If we were talking about how to 
> improve EV, then by all means focus on the edge cases.  The thing I don’t see 
> in all this is a compelling argument to take away something that’s useful 
> most of the time.

My concern with this argument is that it's susceptible to the criticism
that Adam Langley made of revocation checking:
https://www.imperialviolet.org/2012/02/05/crlsets.html

"So [EV identity is] like a seat-belt that snaps when you crash. Even
though it works 99% of the time, it's worthless because it only works
when you don't need it."

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

Re: On the value of EV

[Gervase Markham via dev-security-policy]

On 11/12/17 17:00, Ryan Sleevi wrote:
> Fundamentally, I think this is misleading. It presumes that, upon
> something bad happening, someone can link it back to that certificate
> to link it back to that identity. If I was phished, and entered my
> credentials, there's no reason to believe I've maintained the record
> details including the phishing link to know I was phished. Are users
> supposed to spleunk their HTTP cache or maintain complete archives of
> every link they visited, such that they can get the cert back from it
> to aid an investigation?

This is something that has always worried me about the EV value
proposition. Even if it worked perfectly, once one has realised one has
been scammed, one would want to find the cert again to know where to
serve the lawsuit papers or send the police. Unless your browser caches
all EV certs for sites you've ever visited in the past month, and
provides some UI for querying that cache, then that's not necessarily
going to be possible. So having the info about the site owner in the
cert isn't actually useful.

CT does address this to a degree, but only to a degree.

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

Re: CA generated keys

[Gervase Markham via dev-security-policy]

Hi Tim,

The more I think about it, the more I see this is actually a interesting
question :-)

I suspect the first thing Mozilla allowing this would do would be to
make it much more common. (Let's assume there are no other policy
barriers.) I suspect there are several simpler workflows for certificate
issuance and installation that this could enable, and CAs would be keen
to make their customers lives easier and reduce support costs.

On 09/12/17 18:20, Tim Hollebeek wrote:
> First, third parties who are *not* CAs can run key generation and escrow
> services, and then the third party service can apply for a  certificate for
> the key, and deliver the certificate and the key to a customer.

That is true. Do you know how common this is in SSL/TLS?

> I'm not
> sure how this could be prevented.  So if this actually did end up being a
> Mozilla policy, the practical effect would be that SSL keys can be generated
> by third parties and escrowed, *UNLESS* that party is trusted by Mozilla.

Another way of putting it it: "unless that party were the party the
customer is already dealing with and trusts". IoW, there's a much lower
barrier for the customer in getting the CA to do it (trust and
convenience) compared to someone else. So removing this ban would
probably make it much more common, as noted above. If it's something we
want to discourage even if we can't prevent it, the current ban makes sense.

> Second, although I strongly believe that in general, as a best practice,
> keys should be generated by the device/entity it belongs to whenever
> possible, we've seen increasing evidence that key generation is difficult
> and many devices cannot do it securely.  I doubt that forcing the owner of
> the device to generate a key on a commodity PC is any better (it's probably
> worse).

That's also a really interesting question. We've had dedicated device
key generation failures, but we've also had commodity PC key generation
failures (Debian weak keys, right?). Does that mean it's a wash? What do
the risk profiles look like here? One CA uses a MegaRNG2000 to generate
hundreds of thousands of certs.. and then a flaw is found in it. Oops.
Better or worse than a hundred thousand people independently using a
broken OpenSSL shipped by their Linux vendor?

> With an increasing number of small devices running web servers,
> keys generated by audited, trusted third parties under whatever rules
> Mozilla chooses to enforce about secure key delivery may actually in many
> circumstances be superior than what would happen if the practice is banned.

Is there a way to limit the use of this to those circumstances?

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

Re: Possible future re-application from WoSign (now WoTrus)

[Gervase Markham via dev-security-policy]

On 22/11/17 09:05, Gervase Markham wrote:
> We understand that WoTrus (WoSign changed their name some months ago)
> are working towards a re-application to join the Mozilla Root Program.
> Richard Wang recently asked us to approve a particular auditor as being
> suitable to audit their operations.

Thank you to everyone who contributed to this discussion in a thoughtful
and measured way. Mozilla has emailed WoTrus and Qihoo 360 with our
summary of the sentiment of the group, which we hope will be useful to
them in making their future plans.

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Gervase Markham via dev-security-policy]

On 30/11/17 14:52, Ryan Sleevi wrote:
> I think that, as CAA deployment becomes common, this pattern will be
> not-uncommon. I would hope we don't sound false alarms when it does.

After a little time (as it does seem some bugs are still being shaken
out), I am considering having Mozilla adopt a policy either of:

a) not accepting CAA violation reports from people other than the owners
of the domain in question; or

b) automatically believing the CA if they post a log which shows their
view of the DNS at the time of issuance.

We could start with b), but if CAs get a high load of reports still, we
could move to a).

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

Re: Firefox Mobile - Which Trust Store?

[Gervase Markham via dev-security-policy]

On 27/11/17 19:50, Myers, Kenneth (10421) wrote:
> Does Firefox mobile use the NSS trust store?

Yes, on Android. It uses the OS trust store on iOS.

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

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

[Gervase Markham via dev-security-policy]

On 24/11/17 11:37, Rob Stradling wrote:
> When issuing a "single domain" certificate to (for example)
> www.example.com or *.example.com, it's fairly common practice for CAs to
> also include in the certificate a SAN.dNSName for the "base domain"
> (e.g., example.com).  (Similarly, if the certificate request is for
> example.com, some CAs will add a SAN.dNSName for www.example.com).

IMO these two processes are not at all "similar".

Validate example.com -> add "www.example.com": seems fine to me, and a
reasonable accommodation to a common customer desire.

Validate www.example.com -> add "example.com": not at all fine.

Validate *.example.com -> add "example.com": still dodgy IMO.

I seem to remember we have come across this before, and I thought we
said it was not to be done. But perhaps that didn't make it into our
policy. Do we need to add it?

Gerv



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

Re: Forbidden Practices: Subscriber key generation

[Gervase Markham via dev-security-policy]

On 14/11/17 21:53, Doug Beattie wrote
> The question is, if we issue Code Signing certificates via P12 files
> in compliance with the Code Signing standard, are we out of
> compliance with the Mozilla policy?  How do you recommend we respond
> to this checklist question?

Mozilla does not have policies relating to code signing. We would
therefore expect CAs to arrange things such that their code signing
activities fall outside the scope of the Mozilla policy. The scope
statement in the policy section 1.1, and it seems to me that the easiest
technical way to achieve this is to do code signing activities under an
intermediate which is technically constrained so it cannot issue email
or server certs.

> And the same for S/MIME and SSL certificates.  If CAs generate and
> then securely distribute the keys to the subscribers using similar
> methods, is that permitted provided we implement similar security, or
> does that practice need to immediately stop?  Your guidance in this
> area would be appreciated.

For SSL, I would say it needs to immediately stop. Although see:
https://github.com/mozilla/pkipolicy/issues/107

For S/MIME, as you can see, the Problematic Practices page permits it.

> Side question: Is there a deadline when you expect to receive
> self-assessments from all CAs?  We've found that complying with the
> checklist means a major update to our CPS (among other things...),
> and I suspect most other CAs will also need a major update.

I believe Kathleen did put a date in the CA Communication. If you need
more time, contact certificates@mozilla dot org with your good reasons :-)

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

Re: Possible future re-application from WoSign (now WoTrus)

[Gervase Markham via dev-security-policy]

On 22/11/17 11:41, Tom wrote:
> https://www.wosign.com/english/about.htm has been updated with the new
> name, WoTrus, and currently says "Richard Wang, CEO"

Richard stated to me at one point (I can't remember whether in person or
by email) that at the time of speaking, he was no longer CEO, and they
were looking for a new one, but he was CXO, where the X was, I think, an
O, but might have been a T. So at one point, he did assert that he was
no longer CEO. It seems like, from the website, this has changed.

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

Possible future re-application from WoSign (now WoTrus)

[Gervase Markham via dev-security-policy]

We understand that WoTrus (WoSign changed their name some months ago)
are working towards a re-application to join the Mozilla Root Program.
Richard Wang recently asked us to approve a particular auditor as being
suitable to audit their operations.

In the WoSign Action Items bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311824
Kathleen wrote "WoSign may apply for inclusion of new (replacement) root
certificates[1] following Mozilla's normal root inclusion/change
process[2] (minus waiting in the queue for the discussion), after they
have completed all of the following action items, and no earlier than
June 1, 2017."

However, one step in the inclusion process is the public discussion, and
we have some reason to believe that this may lead to significant
objections being raised. It would not be reasonable to encourage WoSign
to complete all the other steps in the process if there was little or no
chance of them being approved in public discussion.

So Kathleen and I thought it would be best to have a pre-discussion now,
in order to make sure that expectations are set appropriately. If WoTrus
had completed all the action items in the bug and arrived at the public
discussion part of the application, what would people say? If you raise
an objection, please say if there is any way at all that you think
WoTrus could address your issue.

Thanks for your input,

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

Warning about posting via Google Groups

[Gervase Markham via dev-security-policy]

Dear m.d.s.p.,

We appear to again have a problem with messages posted via the Google
Groups web UI making it to all subscribers on the list:
https://bugzilla.mozilla.org/show_bug.cgi?id=1412993

Until that problem is resolved, if you wish to post to the list, please
subscribe to the mailing list version or use the newsgroup gateway:
https://www.mozilla.org/about/forums/#dev-security-policy

The Google Groups UI can still be used for referencing messages, and for
reading the list.

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

Re: November 2017 CA Communication ACTION 1 April 15 2018 date question

[Gervase Markham via dev-security-policy]

On 17/11/17 00:26, Arkadiusz Ławniczak wrote:
> [...] I do not see such requirement in the Policy or even by
> searching m.d.s list..  Maybe I missed something. Does anybody know
> where did it come from?

https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
section 5.3.1.

However, the dates in version 2.5 of the policy have been superceded;
see erratum note on https://wiki.mozilla.org/CA/Root_Store_Policy_Archive .

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

Re: Third party use of OneCRL

[Gervase Markham via dev-security-policy]

On 07/11/17 14:08, niklas.bachma...@googlemail.com wrote:
> I'm working for a big managed security provider. We would like to
> benefit from OneCRL as a means of improving our certificate
> revocation checking.

As in, you'd like to download one copy per day, or you'd like 100,000
clients to download one copy per day?

> I could download OneCRL at
> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records.
> My question is if there is a license on OneCRL or if we are free to
> use it?

We have not put an explicit license on the data but certainly, in
keeping with Mozilla's principles of openness and sharing, it is
available for all to use. However, that doesn't mean our IT team might
not take action against clients making abusively large numbers of
requests. So if your usage of the list might get noticed, it would be
wise to talk to us first.

> Further I'm wondering if Mozilla has already thought about
> third party users and provides another way of getting the most recent
> version of OneCRL than getting the above mentioned website and
> comparing if the content has changed?

What other method might you have in mind that would be better than a
computer-readable highly-available web service? I suspect if you send it
an If-Modified-Since or other similar headers you might also get a Not
Modified response rather than another copy of the data. But look at the
code for Kinto or ask the people who wrote it.

Gerv

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

Re: Estonia e-residency instructing users not to update Firefox (on Mac)

[Gervase Markham via dev-security-policy]

On 02/11/17 11:39, Henri Sivonen wrote:
> A Medium post claiming[1] to represent Estonia e-residency
> https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52
> instructs Mac users not to update Firefox from December 15 2017 onwards.

Thank you for this report; the Estonian e-residency team has updated the
blog post to remove the advice about not updating Firefox.

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

Re: Incident Report : GlobalSign certificates with ROCA Fingerprint

[Gervase Markham via dev-security-policy]

On 03/11/17 18:16, douglas.beat...@gmail.com wrote:
> Here is the final incident report

Thanks, Doug :-)

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

Re: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

Dear Inigo,

On 14/09/17 09:49, Gervase Markham wrote:
> The Mozilla CA Certificates team has been considering what the
> appropriate next steps are for the inclusion request from the CA
> "StartCom".[0] As readers will know, this CA has previously been removed
> from trust[1], and so a re-application obviously involves particular
> scrutiny. In addition, several questions have been raised about the way
> in which the new StartCom PKI has been operated technically[2]. This is
> a proposal for the way forward, on which comments are invited.

A month ago we posted the above re: StartCom, in what was officially a
request for comments. The ensuing discussion did not lead us to conclude
that anything we were asking for was inappropriate. So we want to
formally confirm that it is indeed Mozilla's requirement that StartCom
begin again with a new-new hierarchy and do the other things outlined in
the original post before we will further consider a root inclusion
request from StartCom.

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

Hi Peter,

Ryan is the chain-building expert, and others have deeper knowledge of
how the new Symantec/DigiCert PKI is going to work than I do, but here's
an attempt to answer your question.

On 27/10/17 16:51, Peter Bowen wrote:
> If DigiCert generates a new online issuing CA on 20 March 2018 and
> cross-signs it using their VeriSign Class 3 Public Primary
> Certification Authority - G5 offline root CA, will certificates from
> this new issuing CA be trusted by Firefox?  If so, what are the
> parameters of trust, for example not trusted until the new CA is
> whitelisted by Mozilla or only trusted until a certain date?

Certificates chaining up to Symantec roots, so including that Verisign
one, which have notBefore dates after June 2016 (which I assume these
would) will continue to be trusted until the full removal of trust in
Symantec in October 2018.

They may be trusted beyond that if this new issuing CA is one of the
ones DigiCert asks us to whitelist for Symantec continuity (the "Managed
Partner Infrastructure"). Although I'm generally expecting DigiCert to
create and submit a single list of such CAs at one time, rather than
submitting them in dribs and drabs.

> What about the same scenario except the new issuing CA is generated on
> 30 June 2019?

As the Verisign root would no longer be in our root store, certs issued
by such an issuing CA would no longer ordinarily be trusted. If this
were a whitelisted continuity issuing CA, it might still be trusted. If
I recall correctly, the future trust parameters for those continuity CAs
is undefined by the consensus plan. It says that they will continue to
work until any new Symantec hierarchy is in all the root stores, but
that was defined before the purchase was mooted. So it seems to me like
there is now a question mark here.

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

Re: Francisco Partners acquires Comodo certificate authority business

[Gervase Markham via dev-security-policy]

On 31/10/17 13:21, Kyle Hamilton wrote:
> http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business

Comodo notified Mozilla of this impending acquisition privately in
advance, and requested confidentiality, which we granted. Now that the
acquisition is public, it is reasonable for the community to have a
discussion about the implications for Mozilla's trust of Comodo, if any.

However, there is also another wrinkle to iron out. Our policy 2.5 says:
"If the receiving or acquiring company is new to the Mozilla root
program, there MUST be a public discussion regarding their admittance to
the root program, which Mozilla must resolve with a positive conclusion
before issuance is permitted."

I personally feel that this is a bug, in that technically it says that
as soon as a deal closes and is announced, the CA has to stop issuance
entirely until the Mozilla community has had a discussion and given the
OK. I believe that's not reasonable and would create massive business
disruption if the letter of that rule were enforced strictly. I think
that when we wrote the policy, we didn't anticipate the situation where
the buyer would be confidential until closing. (Compare Digimantec,
where it's not.)

So it would also be useful to have a discussion about what this section
of the policy should actually say.

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

Re: ETSI audits not listing audit periods

[Gervase Markham via dev-security-policy]

Hi Arno,

On 31/10/17 08:46, Arno Fiedler wrote:
> there is a problem with the auditor qualification and the national 
> accreditation of some auditing bodies.

Can you help us understand what about the discussion so far leads you to
that conclusion? It seems to me that the problem being raised is with
the very nature of ETSI audits, not with the qualifications of the
auditor or with national accreditation.

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

On 18/10/17 13:49, Gervase Markham wrote:
> Apple have confirmed that their list is complete and correct.

As have Google.

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

Re: DRAFT November 2017 CA Communication

[Gervase Markham via dev-security-policy]

On 27/10/17 00:23, Kathleen Wilson wrote:
> Looking forward to further discussion about which errata should be allowed.

Those are the correct two errata.

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

Re: Proposed policy change: require private pre-notification of 3rd party subCAs

[Gervase Markham via dev-security-policy]

Hi Doug,

On 24/10/17 16:43, Doug Beattie wrote:
> I assume this applies equally to cross signing,

Yes.

> but not to "Vanity" CAs that are set up and run by the CA on behalf of a 
> customer.  

If you have physical control of the intermediate and control of
issuance, it doesn't apply.

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

Proposed policy change: require private pre-notification of 3rd party subCAs

[Gervase Markham via dev-security-policy]

One of the ways in which the number of organizations trusted to issue
for the WebPKI is extended is by an existing CA bestowing the power of
issuance upon a third party in the form of control of a
non-technically-constrained subCA. Examples of such are the Google and
Apple subCAs under GeoTrust, but there are others.

Adding new organizations to the list of those trusted is a big deal, and
currently Mozilla has little pre-insight into and not much control over
this process. CAs may choose to do this for whoever they like, the CA
then bears primary responsibility for managing that customer, and as
long as they are able to file clean audits, things proceed as normal.

Mozilla is considering a policy change whereby we require private
pre-notification of such delegations (or renewals of such delegations).
We would not undertake to necessarily do anything with such
notifications, but lack of action should not be considered permissive in
an estoppel sense. We would reserve the right to object either pre- or
post-issuance of the intermediate. (Once the intermediate is issued, of
course, the CA has seven days to put it in CCADB, and then the
relationship would probably become known unless the fields in the cert
were misleading.)

This may not be where we finally want to get to in terms of regulating
such delegations of trust, but it is a small step which brings a bit
more transparency while acknowledging the limited capacity of our team
for additional tasks.

Comments are welcome.

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

On 17/10/17 10:01, Gervase Markham wrote:
> Here's an informal list created by me examining the CCADB. Note that the
> CCADB links won't work for anyone except Root Store operators.

Apple have confirmed that their list is complete and correct.

Gerv

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

On 17/10/17 15:50, Ryan Sleevi wrote:
> That doesn't seem to line up with the discussion in
> https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2IeuZtw/discussion
> to date. Do you have any additional information to share?
> 
> Note that the path you just described is the one that poses non-trivial
> risk to the ecosystem, from an interoperability standpoint, and thus may
> not be desirable.

This seems to be because I'm not following closely enough. The exact
design of complex PKIs is not my area :-) I'm sure the people who are
experts will work it all out.

But yes, in general, the point of the managed CAs is that they will
continue to be trusted, somehow, for some additional period of time.

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

On 16/10/17 20:19, Daniel Cater wrote:
> Could we have a list of the subCAs that are being considered for exemption 
> for the distrust?

Here's an informal list created by me examining the CCADB. Note that the
CCADB links won't work for anyone except Root Store operators.


GeoTrust Global CA
 |
 |_ Google Internet Authority G2 (2017-05-22 -> 2018-12-31)
 |  https://ccadb.my.salesforce.com/0011J17aa6MQAQ
 |  https://crt.sh/?id=142951186
 |
 |_ Google Internet Authority G2 (2015-04-01 -> 2017-12-31)
https://ccadb.my.salesforce.com/001o00utwbKAAQ
https://crt.sh/?id=23635000

GeoTrust Global CA
 |
 |_ Apple IST CA 2 - G1
 |  https://ccadb.my.salesforce.com/001o00p4ScGAAU
 |  https://crt.sh/?id=5250464
 |
 |_ Apple IST CA 5 - G1
https://ccadb.my.salesforce.com/001o00p4ScnAAE
https://crt.sh/?id=12716200

GeoTrust Primary Certification Authority - G2
 |
 |_ Apple IST CA 4 - G1
 |  https://ccadb.my.salesforce.com/001o00p4ScIAAU
 |  https://crt.sh/?id=19602712
 |
 |_ Apple IST CA 7 - G1
 |  https://ccadb.my.salesforce.com/001o00p4ScIAAU
 |  https://crt.sh/?id=19602724
 |
 |_ Apple IST CA 8 - G1
https://ccadb.my.salesforce.com/001o00qRJHFAA4
https://crt.sh/?id=21760447

GeoTrust Primary Certification Authority - G3
 |
 |_ Apple IST CA 3 - G1
 |  https://ccadb.my.salesforce.com/001o00p4SciAAE
 |  https://crt.sh/?id=19602706
 |
 |_ Apple IST CA 6 - G1
https://ccadb.my.salesforce.com/001o00p4ScoAAE
https://crt.sh/?id=19602741

I will get Google and Apple to validate this data.

Gerv

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

Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

As per previous discussions and
https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
reached among multiple browser makers for a graduated distrust of
Symantec roots.

Here is Mozilla’s planned timeline for the graduated distrust of
Symantec roots (subject to change):

* January 2018 (Firefox 58): Notices in the Developer Console will warn
about Symantec certificates issued before 2016-06-01, to encourage site
owners to migrate their TLS certs.

* May 2018 (Firefox 60): Websites will show an untrusted connection
error if they have a TLS cert issued before 2016-06-01 that chains up to
a Symantec root.

* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
caveats described below.

Mozilla’s release calendar is here:
https://wiki.mozilla.org/RapidRelease/Calendar

However, there are some subCAs of the Symantec roots that are
independently operated by companies whose operations have not been
called into question, and they will experience significant hardship if
we do not provide a longer transition period for them. For both
technical and non-technical reasons, a year is an extremely unrealistic
timeframe for these subCAs to transition to having their certificates
cross-signed by another CA. For example, the subCA may have implemented
a host of pinning solutions in their products that would fail with
non-Symantec-chaining certificates, or the subCA may have large numbers
of devices that would need to be tested for interoperability with any
potential future vendor. And, of course contractual negotiations may
take a significant amount of time.

The subCAs that we know of that fall into this category belong to Google
and Apple. If there are any other subCAs that fall into this category,
please let us know immediately. Google has one such subCA; Apple has seven.

There are two ways that we can provide a smoother transition for these
subCAs.

Option 1)
Temporarily treat these subCAs as directly-included trust-anchors.
Mozilla prefers *not* to take this approach, because even if clearly
explained up front that it is a temporary solution with deadlines, it
would be very easy for people to start treating such a subCA as a
regular trust anchor, and thereby have that subCA become a de facto
included CA. Additionally, it could become very complicated to remove
such subCAs in the future, especially if they have not performed the
recommended transitions.

Option 2)
Add code to Firefox to disable the root such that only certain subCAs
will continue to function. So, the final dis-trust of Symantec roots may
actually involve letting one or two of the root certs remain in
Mozilla’s trust store, but having special code to distrust all but
specified subCAs. We would document the information here:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
And Mozilla would add tooling to the CCADB to track these special subCAs
to ensure proper CP/CPS/audits until they have been migrated and
disabled, and the root certs removed. Mozilla will need to also follow
up with these subCAs to ensure they are moving away from these root
certificates and are getting cross-signed by more than one CA in order
to avoid repeating this situation.

According to option 2 and the plan listed above, here is how the
currently-included Symantec root certs will be treated in Firefox 63:

= Symantec roots to be disabled via code, *not* removed from NSS =

GeoTrust Global CA
GeoTrust Primary Certification Authority - G2
GeoTrust Primary Certification Authority - G3

= Symantec roots that will be fully removed from NSS =

GeoTrust Primary Certification Authority
GeoTrust Universal CA
GeoTrust Universal CA 2
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G6
thawte Primary Root CA
thawte Primary Root CA - G2
thawte Primary Root CA - G3
VeriSign Class 1 Public PCA - G3
VeriSign Class 2 Public PCA - G3
VeriSign Class 3 Public Primary Certification Authority - G3
VeriSign Class 3 Public Primary Certification Authority - G4
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign Universal Root Certification Authority

As always, we appreciate your thoughtful and constructive feedback on this.

Gerv

[0]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D

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

Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

As per previous discussions and
https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
reached among multiple browser makers for a graduated distrust of
Symantec roots.

Here is Mozilla’s planned timeline for the graduated distrust of
Symantec roots (subject to change):

* January 2018 (Firefox 58): Notices in the Developer Console will warn
about Symantec certificates issued before 2016-06-01, to encourage site
owners to migrate their TLS certs.

* May 2018 (Firefox 60): Websites will show an untrusted connection
error if they have a TLS cert issued before 2016-06-01 that chains up to
a Symantec root.

* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
caveats described below.

Mozilla’s release calendar is here:
https://wiki.mozilla.org/RapidRelease/Calendar

However, there are some subCAs of the Symantec roots that are
independently operated by companies whose operations have not been
called into question, and they will experience significant hardship if
we do not provide a longer transition period for them. For both
technical and non-technical reasons, a year is an extremely unrealistic
timeframe for these subCAs to transition to having their certificates
cross-signed by another CA. For example, the subCA may have implemented
a host of pinning solutions in their products that would fail with
non-Symantec-chaining certificates, or the subCA may have large numbers
of devices that would need to be tested for interoperability with any
potential future vendor. And, of course contractual negotiations may
take a significant amount of time.

The subCAs that we know of that fall into this category belong to Google
and Apple. If there are any other subCAs that fall into this category,
please let us know immediately. Google has one such subCA; Apple has seven.

There are two ways that we can provide a smoother transition for these
subCAs.

Option 1)
Temporarily treat these subCAs as directly-included trust-anchors.
Mozilla prefers *not* to take this approach, because even if clearly
explained up front that it is a temporary solution with deadlines, it
would be very easy for people to start treating such a subCA as a
regular trust anchor, and thereby have that subCA become a de facto
included CA. Additionally, it could become very complicated to remove
such subCAs in the future, especially if they have not performed the
recommended transitions.

Option 2)
Add code to Firefox to disable the root such that only certain subCAs
will continue to function. So, the final dis-trust of Symantec roots may
actually involve letting one or two of the root certs remain in
Mozilla’s trust store, but having special code to distrust all but
specified subCAs. We would document the information here:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
And Mozilla would add tooling to the CCADB to track these special subCAs
to ensure proper CP/CPS/audits until they have been migrated and
disabled, and the root certs removed. Mozilla will need to also follow
up with these subCAs to ensure they are moving away from these root
certificates and are getting cross-signed by more than one CA in order
to avoid repeating this situation.

According to option 2 and the plan listed above, here is how the
currently-included Symantec root certs will be treated in Firefox 63:

= Symantec roots to be disabled via code, *not* removed from NSS =

GeoTrust Global CA
GeoTrust Primary Certification Authority - G2
GeoTrust Primary Certification Authority - G3

= Symantec roots that will be fully removed from NSS =

GeoTrust Primary Certification Authority
GeoTrust Universal CA
GeoTrust Universal CA 2
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G6
thawte Primary Root CA
thawte Primary Root CA - G2
thawte Primary Root CA - G3
VeriSign Class 1 Public PCA - G3
VeriSign Class 2 Public PCA - G3
VeriSign Class 3 Public Primary Certification Authority - G3
VeriSign Class 3 Public Primary Certification Authority - G4
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign Universal Root Certification Authority

As always, we appreciate your thoughtful and constructive feedback on this.

Gerv

[0]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposed change to CA contact policy

[Gervase Markham via dev-security-policy]

On 09/10/17 18:04, Matthew Hardeman wrote:
> Echoing Mr. Lamb's concern, I would think that defining two
> "important notice role/mailing list recipient addresses" and always
> sending important notices to both.  This would allow for a mailing
> list on CA internal infrastructure as well as one on external
> infrastructure.

Kathleen now says she would prefer to email the Primary POCs and CC the
email aliases. Handily, this allows for what you suggest. So consider
the proposal changed to that.

Gerv

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

Re: Issuing and using SHA-1 OCSP signing certificates

[Gervase Markham via dev-security-policy]

On 03/10/17 18:35, Doug Beattie wrote:
> The specific issue is that these client certificate CAs don't have
> the EKU extension even though we have no intent of issuing SSL
> certificates (they are WT audited and verified to not issue any SSL
> certificates per the BRs).

Would it be an acceptable solution to add these intermediates to OneCRL?

> Is it permissible to continue issuing SHA-1 OCSP signing certificates
> for these existing legacy non-SSL CAs so we may continue providing
> revocation services using algorithms they support until all
> certificates under the CAs expire?  This would be no later than the
> end of 2020.

Can anyone see any problems with an answer to Doug which says that he
may do this once the intermediates are in OneCRL?

Gerv

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

Re: CAA reporting support and tests?

[Gervase Markham via dev-security-policy]

On 26/09/17 00:03, Andrew wrote:
> is that the reports should only be sent in a situation where a
> certificate _would_ have been issued if not for the CAA records.

I'd say that's right. I'd think that by far the more common use case
would be internal policy enforcement at a company rather than detecting
a 3rd party attacker. And given that it's often just "send an email",
one hopes the iodef might not be too onerous for CAs to implement. I
believe we scoped it down to only having to support http: and mailto:.

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

Re: DigiCert-Symantec Announcement

[Gervase Markham via dev-security-policy]

On 26/09/17 03:17, Ryan Sleevi wrote:
> update in a year, are arguably outside of the scope of ‘reasonable’ use
> cases - the ecosystem itself has shown itself to change on at least that
> frequency.

Is "1 year" not a relatively common (for some value of "common") setting
for HPKP timeouts for sites which think they have now mastered HPKP?

Does anyone have stats on HPKP prevalence and duration distribution?
Ideally combined with whether the longer time periods are pinning to
roots, intermediates or EE certs?

Gerv

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

Re: PROCERT decision

[Gervase Markham via dev-security-policy]

On 22/09/17 00:33, Andrew wrote:> Will there be any sort of deprecation
period for PROCERT certificates
> as with StartCom/Wosign & Symantec? Or is PROCERT small enough that
> you believe it's feasible to just immediately distrust them without
> any significant negative impact on the overall web ecosystem?

Kathleen has stated her current plan is to roll this change into the
October batch of root changes, which will ship with Firefox 58.

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

Re: Old roots to new roots best practice?

[Gervase Markham via dev-security-policy]

On 20/09/17 03:49, userwithuid wrote:
>> I agree, Gerv's remarks are a bit confusing with respect to the concern.

Ryan is polite. :-)

> Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part 
> then and should probably be acknowledged as such, @Gerv.

Yes, I acknowledge that this point was confusing; I should have said
something more like this:

>> However, there is a criticism to be landed here - and that's using the same
>> name/keypair for multiple intermediates and revoking one/some of them. This
>> creates all sorts of compatibility problems in the ecosystem, and is thus
>> unwise practice.

Gerv

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

Re: DigiCert mis-issuance report: rekeyed certificates

[Gervase Markham via dev-security-policy]

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1401407 .

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

On 27/09/17 18:54, Matthew Hardeman wrote:
> In the case of StartCom, I can not help but feel that they are being
> held to an especially high standard (higher than other prior adds to
> the program) in this new PKI because of who they are -- despite the
> fact that management and day-to-day decisions are a completely
> different team.
> 
> Where I am headed with this is a concern that perhaps no amount of
> technical remediation can really get these entities back in the
> graces of the community.

I don't know if it's quite as absolute as that, but recent incidents
have caused me to ponder somewhat on the nature of trust. The root
program is all about trust, and trust is not something which can be
encoded in audits, checkboxes and rules. This will always be a tension
at the heart of our root program - we are trying to be as objective as
we can about something which is ultimately subjective.

The nature of trust is that it's harder to regain than it is to gain in
the first place. Just ask someone who's been the victim of adultery - or
someone who is a now-repentant adulterer. Rightly or wrongly, people get
a first chance, but it's tough to get a second. I think you are right
when you conclude that this is just the way of things, and we should
accept it rather than kick against it.

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

Re: Incident Report format

[Gervase Markham via dev-security-policy]

On 22/09/17 00:12, Ryan Sleevi wrote:
> Based on the number of reports reviewed recently, I suspect we've got
> opportunities for improvement, but I'm not quite sure yet what the concrete
> suggestions on that should look like. A few thoughts below:

Here's a set of changes which attempt to capture some of what you are
requesting. Further input, from you or others, is welcome.

https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_A_Misissuance=1181405=1179230

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

PROCERT decision

[Gervase Markham via dev-security-policy]

The CA Certificates module owner and peers have come to a decision
regarding our investigations into the activities of the CA "PROCERT".

A large number of issues were raised regarding the operations and
practices of this CA:
https://wiki.mozilla.org/CA:PROCERT_Issues

Considering them, it seems clear to us that PROCERT have not been, and
continue not to be, adequately aware of the requirements placed upon
them by various RFCs, the CA/Browser Forum's Baseline Requirements, and
Mozilla Root Store Policy. They have not demonstrated sufficient control
of their issuance pipeline or sufficient checking of the results to
avoid regularly creating certificates which violate the requirements of
one or more of those documents. PROCERT have also made assurances to us,
via responses to CA Communications, that certain things were true which
are manifestly not so (e.g. that they were using properly-randomized
serial numbers).

In addition, PROCERT's response to these issues was inadequate. While
they revoked (most, but not all, of) the certificates which were flagged
as problematic, their written responses have been limited in number and
are very superficial. In some cases, it is clear that they have not
understood the issue that was raised. They have not, to our knowledge,
performed any root cause analysis which might allow us to have some
confidence that problems of this or a similar nature will not recur. We
have very little insight into their systems and what, if any, safeguards
they have in place.

It seems that PROCERT's belief is that revocation is an adequate remedy
for all of the problems listed. We disagree. Therefore, we feel we can
no longer trust PROCERT, and plan to proceed with removing their
"PSPProcert" certificate from our root program and root store.

Kathleen Wilson
Gervase Markham
Ryan Sleevi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident Report format

[Gervase Markham via dev-security-policy]

It seems like the list of topics to cover on the Responding to a
Misissuance page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
has become a de facto template for incident reports.

We've now had quite a few CAs use this outline to respond to issues. If
people (CAs or others) have feedback on how this template could be
improved, that would be a fine thing.

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

Re: Public trust of VISA's CA

[Gervase Markham via dev-security-policy]

Additionally, 13 days ago it was reported to VISA that their OCSP
responder was misconfigured to return "good" responses for non-existent
certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261
As far as I can see, this is the case for their end-entity certificates,
not just some roots or intermediates.

Two weeks later, they have not yet provided any response.

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

Re: Public trust of VISA's CA

[Gervase Markham via dev-security-policy]

On 19/09/17 16:27, Peter Bowen wrote:
> I think your statement is a little broad.  Every CA only issues
> certificates to themselves and their own customers (or as the BRs call
> them "Subscribers").  

Yes, you are right. "Customers" was the wrong word. Perhaps I rather
meant they only issue to "organizations with whom they have a business
relationship which does not centre around certificates"? Or something
like that.

> The included CAs list

i.e.
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

> indicates it never followed the current Mozilla
> inclusion process, but is one of four "legacy" CAs.  

(See column "Approval Bug")

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

Re: FW: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

Hi Inigo,

On 15/09/17 17:30, Inigo Barreira wrote:
> There wasn´t a lack of integrity and monitoring, of course not. All PKI logs 
> were and are signed, it´s just the auditors wanted to add the integrity to 
> other systems which is not so clear that should have this enabled. For 
> example, if you want to archive database information for not managing a big 
> one, the integrity of the logs could be a problem when trying to "move" to an 
> archive system. I had some discussions about the "scope" of the integrity. 
> Regarding the monitoring, well, we monitor many things, in both data centers, 
> 24x7, etc. For this specific issue, it´s true that we didn´t have it 
> automatically but manually, but well, and we implement a solution, but this 
> is not a lack of monitoring. I think the audits are to correct and improve 
> the systems and don´t think any CA at the first time had everything correct. 
> So, for example, I thought this finding was good because made us improve.
> 
>> Repairing them afterwards does not remove the uncertainty.
> 
> Well, then any issue that you could find, even repaired or fixed, does not 
> provide you any security and hence you should not trust anyone. 

Not so. There is particular concern about issues with auditing and
monitoring. For other issues, you can check the logs to see whether a
particular bug was abused. If the auditing or monitoring is broken or
inadequate, you can't tell what happened.

>> I may have made a mistake here. I was under the impression that you had
>> told me that your new hierarchy, cross-signed by Certnomis, had issued
>> 50,000 certificates. Did I misunderstand? If so, my apologies.
> 
> No, or not totally. We have issued those certs but not cross-signed by 
> Certinomis because we didn´t have the cross-signed certificates so, all of 
> them were issued under the new startcom hierarchy

But once the cross-signed cert is publicly available (and it is; it's in
CT, however it got there), all of those certificates become trusted (or
potentially trusted, if the owner reconfigures their webserver to serve
the intermediate, or if Firefox has already encountered it in the
current browsing session).

> This is something I don´t understand. Why do you say the audits I presented 
> don´t meet the BRs? Because of the findings? The auditors indicate those were 
> fixed 

I don't believe there's a formal way for an auditor to bindingly say "by
the way, the problems we found have since been fixed" in an audit
report. But to help me understand: exactly what statement on what page
of your audit report(s) are you referring to here?

> About the remediation steps, well, I answered the bug about it providing all 
> the info and yes, you haven´t answered yet nor to approve nor to deny.

Right. So why are you proceeding?

You might reasonably complain it's taken us a while to respond to that
comment about the steps. Yes, it has. The Mozilla inclusion process is
slow. :-(

>>> In fact, recently, I asked for permission to use the Certinomis cross-signed
>> certificates and have no response. I don´t know if this is an administrative
>> silence which may allow me to use it but until having a clear direction we
>> haven´t used it.
>>
>> Can you remind me how you asked and when?
> 
> It was in an email of sept 4th, titled "StartCom communication" in which at 
> the end of the long email I asked for feedback to use the cross-signed 
> certificates and give additional explanations

I have no record of any email with that title, or any email from you
between 15th August ("Re: Problem Reporting Mechanism") and 11th
September ("Re: Remove old Startcom roots from NSS"). Where did you send it?

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

Re: CAs not compliant with CAA CP/CPS requirement

[Gervase Markham via dev-security-policy]

On 15/09/17 09:38, richmoor...@gmail.com wrote:
> I suspect many smaller CAs are non-compliant too, for example gandi's CPS 
> hasn't changed since 2009 according to its changelog.
> 
> https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf

Thank you for bringing this to my attention; I have emailed Comodo to
ask them what the situation is here.

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

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

On 13/09/17 23:57, Matthew Hardeman wrote:
> This is especially the case for CAA records, which have an explicit security 
> function: controlling, at a minimum, who may issue publicly trusted 
> certificates for a given FQDN.

I'd be interested in your engagement on my brief threat modelling; it
seems to me that DNSSEC only adds value in the scenario where an
attacker has some control of CA Foo's issuance process, but not enough
to override the CAA check internally, but it also has enough control of
the network (either at the target, or at the CA) to spoof DNS responses
to defeat CAA. That seems on the surface like a rare scenario.

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

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

Hi Nick,

On 13/09/17 20:39, Nick Lamb wrote:
> Gerv, rather than start by digging into the specific technical details, let 
> me ask a high level question.
> 
> Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA 
> record saying to only permit the non-existent Gotham Certificates 
> gotham.example to issue.
> 
> You say you don't want CAs to need to implement DNSSEC. But you also don't 
> want them issuing for my domain. How did you imagine this circle would be 
> squared?

There seems to have been some progress made on the CAB Forum list in
terms of defining exactly what it means for a domain to have or not have
DNSSEC, and how a CA can determine that.

It might also be worth thinking about the value that DNSSEC adds, over
and above a non-secure CAA check, in various attack scenarios. At the
moment, I'm thinking that DNSSEC doesn't necessarily add much. Here are
3 quick scenarios, for a domain which is CAA locked so only CA Bar can
issue:

* Misguided employee tries to get CA Foo to issue for your domain - in
which case, non-DNSSEC-signed checking will do.

* Attacker has some control of CA Foo but can't override CAA check - in
which case, non-DNSSEC-signed checking will do.

* Attacker has control of CA Foo but can override CAA check - in which
case, it doesn't matter what your DNS says.

Gerv

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

Re: FW: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

Hi Franck,

On 18/09/17 15:49, Franck Leroy wrote:
> Our understanding in April was that as long as StartCom is not
> allowed by Certinomis to issue EE certs, the disclosure was not
> mandated immediately.

I think that we need to establish a timeline of the exact events
involved here.

But I would say that it seems to me that Startcom _were_ issuing EE
certs at that time, from the part of their hierarchy that you had
cross-signed. In what way was Certnomis forbidding them from doing so?
My understanding is that your answer to this question is...

> This control that StartCom was not allowed to use our path was
> technical in place by the fact that I was the only one to have the
> intermediate cross signed certificates, stored (retained) in my
> personal safe.

that you had not given Startcom a copy of the cross-sign. However,
leaving aside for the moment the reasonable question about how such an
assertion can be audited, the point is that once the certificate _does_
become public, all of the existing certificates immediately become
publicly trusted. Wouldn't you agree?

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

Re: FW: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

On 15/09/17 15:35, Inigo Barreira wrote:
> No, those weren´t tests. We allowed the use of curves permitted by the BRs 
> but this issue came up in the mozilla policy (I think Arkadiusz posted) and I 
> also asked about it in the last CABF F2F (I asked Ryan about it) and then, 
> with that outcome and as the browsers didn´t accept them, we revoked and then 
> not allow the issuance. I think the discussion is still active (i.e. the use 
> of P-521).

Unless Mozilla says otherwise (which we do occasionally), you should not
be basing your practice on what we are discussing, or even on draft
versions of the policy, but on the published version - which clearly
prohibits P-521.

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

On 11/09/17 12:03, Gervase Markham wrote:
> Thank you for this initial response. It is, however, far less detailed
> than we would like to see. 

I have not had any further updates from PROCERT. I have tried to reflect
their responses from this email here:
https://wiki.mozilla.org/CA:PROCERT_Issues

We hope to conclude the discussion at the end of this week, although I
am having minor surgery on Wednesday, so it may be next week.

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

Re: Permission to use Errata CAA Algorithm

[Gervase Markham via dev-security-policy]

On 15/09/17 20:24, j...@letsencrypt.org wrote:
> We would like to ask the Mozilla and Google root programs on this list to 
> immediately grant at least temporary dispensation for CAs to implement the 
> CAA checking algorithm as described in this errata:
> 
> https://www.rfc-editor.org/errata/eid5065

Mozilla's current position on CAA checking algorithms is as follows.

CAA is now mandatory. As such, we expect all CAs to be making good faith
efforts to either:

a) do the algorithm in RFC6844, or
b) do the algorithm in RFC6844, as amended by erratum 5065

Once a motion passes in the CAB Forum to update the BRs to require b), I
would expect CAs in category a) to move to category b) within a
reasonable amount of time, such as 3 months. (If the motion fails, I
would expect the reverse.)

So yes, CAs which wish to do b) may do so according to Mozilla. If such
"non-compliance" ends up on an audit report, Mozilla will not consider
that material or concerning.

There is apparently also an open question about DNAME handling, and
another erratum which clarifies things, but my understanding is that the
RFC is open to two interpretations, one compatible with the algorithms
in the DNAME RFC, and one not. And that no-one uses DNAME in the wild
except people trying to test CAA ;-) So until I understand the situation
better, my general approach is that CAs may do whatever they can
reasonably justify as consistent with the RFC when it comes to DNAME.

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

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[Gervase Markham via dev-security-policy]

On 15/09/17 13:55, cornelia.enk...@gmail.com wrote:
> technically the CA now is disabled to sign certificates using SHA1

But presumably you thought that was true before this incident? (And if
not, why not?)

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

Re: FW: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

On 15/09/17 09:24, Inigo Barreira wrote:
> AFAIK, Certinomis only disclosed in the CCADB 

That means it's published and available. As noted in my other reply,
information as to exactly what this cross-sign enables trust for would
be most helpful, as I may have misunderstood previous statements on this
topic.

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

Re: FW: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

Hi Inigo,

On 14/09/17 16:05, Inigo Barreira wrote:
> Those tests were done to check the CT behaviour, there was any other testing 
> of the new systems, just for the CT. 

Is there any reason those tests could not have been done using a
parallel testing hierarchy (other than the fact that you hadn't set one up)?

> Some of these "mis-issuances" were due to some incongruencies between the BRs 
> and the Mozilla policy, such as the use of different curves (allowed by the 
> BRs but not for some browsers),

But it is the job of a CA to be aware of browser policies.

> As far as I know, the current manager of Startcom has not been previously 
> accused of deception or bad action.

No, indeed. There is no accusation that you have been deceptive towards
anyone.

> Yes, it´s not a policy violation. As explained, this was a problem in the 
> EJBCA with the UTF8 encoding. 

That was the reason for the revocation; it's not the reason for the key
reuse.

>> * The WT/BR/EV audits on StartCom's website are significantly qualified, and
>> they include lack of controls on issuance. They should have clean ones done
>> before we permit any inclusion request to proceed. The qualifications 
>> include:
>>
>> - Risk analysis process defined but not implemented
>> - Business continuity plan defined but not implemented
>> - Audit logs not guaranteed to have integrity
>> - Monitoring system cannot detect security-related changes to
>>   Certificate Systems
> 
> Yes, this is also true. Our webtrust audits have findings but those are not 
> so significant according to the auditors who signed the reports, so I assume 
> the auditors thought that the system is good enough to have the audit report 
> in place.

I think lack of monitoring and lack of integrity of logs are serious
issues. Repairing them afterwards does not remove the uncertainty. If
you said "I left the root certificate private key on a USB stick on the
desk in my unlocked office over the weekend - but it's OK, I've
remediated the problem now, and it's back in the safe", that would not
remove the uncertainty about whether someone had done something with it
in the mean time.

> I don´t know how these you mention have applied, but I remember lots of 
> issues regarding Google and the acquisition of the Globalsign roots and how 
> they proceeded. 

I think "lots of issues" is an overstatement. There was an issue
regarding the scope of their audits which was raised publicly, but it
was something that Google has explicitly sought our approval for in advance.

> Not sure about this. We were distrusted in october 2016, the new system 
> started to operate in april 2017, which is not related to the old one which 
> has been switched off. None of the new certs are trusted in Mozilla Firefox 
> and we notify our users so by messages in the web and applications.

I may have made a mistake here. I was under the impression that you had
told me that your new hierarchy, cross-signed by Certnomis, had issued
50,000 certificates. Did I misunderstand? If so, my apologies.

> Ok, I see this is a new requirement that was not imposed last time in which 
> you recommended and allowed us to be cross-signed as many other CAs have done 
> in the past to be in the business.

Mozilla did not recommend that you be cross-signed. Certnomis raised the
possibility, and we said that it could happen when you had met the BRs
and completed the remediation steps. The plan we "approved" was not a
cross-signing plan. The audits show you haven't yet met the BRs, and we
have not yet signed off on you having completed the remediation steps.

> We´ve met all the conditions, new system, new management, security audit and 
> webtrust audit and CT logging. In those conditions, it was not mentioned that 
> the webtrust audit should be clean 

Isn't that implied?

> I´ve never said this. In fact, despite having that cross-signed which were 
> provided to us in july we have never used and provided to any of our 
> customers to build a trusted path. So none of those 5, or the new ones, 
> go with the Certinomis path because none have it. But all those 5 certs 
> are untrusted because we´re not in the Mozilla root, not the new one, and the 
> old one was distrusted.

So the 50,000 certs you mentioned are issued in your old hierarchy,
which is not cross-signed by Certnomis?

If you could clarify the numbers for your old and new PKI, and confirm
that the Certnomis cross-signs apply only to the new one, that would be
helpful. Again, apologies for any misunderstanding on my part.

> In fact, recently, I asked for permission to use the Certinomis cross-signed 
> certificates and have no response. I don´t know if this is an administrative 
> silence which may allow me to use it but until having a clear direction we 
> haven´t used it. 

Can you remind me how you asked and when?

> I think this has been explained. I don´t understand why you say it´s a "poor 
> quality PHP code". 

Because poor quality PHP code does 

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

On 11/09/17 22:28, Jeremy Rowley wrote:
> I would support that.  I can't recall why it's in there.

As the drafter of the section :-), my intent was to make it so that if a
site owner were concerned about the possibility that their CAA record or
DNS could be spoofed, they could use DNSSEC to solve the problem. I
agree that there is an implicit assumption in this requirement, that it
is possible to efficiently determine the presence or absence of what we
might call "attempted DNSSEC" for a particular domain. (That's not the
same thing as "correct, valid, properly-signed, whatever DNSSEC.) If
that assumption is not true, we may have to reconsider.

I also seem to recall that the intent was not to require that CAs do
proper DNSSEC lookups for all CAA requests as long as they were happy to
fail closed in the presence of DNSSEC. This again has the above implicit
assumption baked into it.

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

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

On 09/09/17 10:21, Jeremy Rowley wrote:
> Certificate 1 contains a single DNS identifier for
> big.basic.caatestsuite.com  .  This DNS
> name has a CAA resource record set that is too large to fit within a single
> DNS UDP packet, but small enough to fit within a DNS TCP packet.  The only
> CAA record containing an issue property is:
> 
> big.basic.caatestsuite.com  . IN
> CAA 0 issue "caatestsuite.com  "
> 
> Therefore, only caatestsuite.com   is allowed to
> issue for this identifier.

>From the discussion so far, I'd say that this one is clearly a
misissuance, and needs treating as one. (I see this as a clever vuln,
not as CA implementation incompetence.)

The jury is still out on the CNAME and DNSSEC-based reports.

Gerv

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

Re: StartCom cross-signs disclosed by Certinomis

[Gervase Markham via dev-security-policy]

Hi Franck,

On 03/08/17 08:59, Franck Leroy wrote:
> On end of June the audit report form PwC was available but with still some 
> minor issues. I asked StartCom to correct them.
> 
> On July 14th the audit report and the policy were updated and published on 
> StartCom website.

The audit reports on StartCom's website
 are dated at the end of June, and
have significant qualifications. E.g.:
https://www.startcomca.com/pwc-webtrust-ca-2017.pdf

What updates to the audit reports were made on July 14th?

Do you consider these audit reports sufficient to say the StartCom has
passed these audits, despite the qualifications therein?

Gerv

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

Re: CAs not compliant with CAA CP/CPS requirement

[Gervase Markham via dev-security-policy]

Hi Ben and Jeremy,

On 09/09/17 01:25, Ben Wilson wrote:
> Those are typos.  See section 4.2.1 of our CPS posted here:
> https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 

This reads:

"The Certification Authority CAA identifying domains for CAs within
DigiCert’s operational control are “digicert.com”, “digicert.ne.jp”,
"cybertrust.ne.jp”, and any domain containing those identifying domains
as suffixes (e.g. *.digicert.com)."

This latter part, while not perhaps being against the letter of the RFC,
is somewhat unhelpful for people who want to write software working with
CAA, because they now can't just load it with a per-CA list of valid
domain names, but have to post-process and stem the value in this case.
Are you certain you need that provision?

Gerv

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

Hi Alejandro,

Thank you for this initial response. It is, however, far less detailed
than we would like to see. In the email I sent to you letting you know
that we were looking at PROCERT, I wrote:

"You may wish to review a similar issue list we created for Symantec:
https://wiki.mozilla.org/CA:Symantec_Issues
in order to see how such a wiki page might develop in the future. For
example, we would expect most or all issues on your list to soon carry a
"PROCERT Response" section. Good responses will be more than "yes, we
have revoked the certificate" or even "we have revoked, and updated our
software". We want to know how each problem occurred in the first place,
and why it was not detected until now by PROCERT's existing systems for
quality control. This wiki page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance
gives best practices in responding to incidents and writing reports,
which may prove useful in formulating your responses."

It seems you have chosen not to follow this advice, as many of your
responses consist solely of an assertion that you have revoked and
replaced the problematic certificates. So, because there is no root
cause analysis, we have no assurance at all that the issue will not
occur again.

Even beyond that major concern, I think there are some of these issues
where you have not entirely understood the problem.

On 08/09/17 20:09, PSC Procert wrote:
> Issue E: Issuance of 1024-bit Certificate (December 2016)
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate in 2048, 
> supporting into the installation process. We completed those actions in this 
> point.

Your cut-and-paste answer is inapplicable in this case, because the
"client" was PROCERT itself - the certificate in question was an OCSP
responder cert.

> Issue L: helloburgershack.com (June - July 2017)
> 
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate, supporting 
> into the installation process. This client provides a production window after 
> the next Tuesday in order to proceed with the revoke and the reissue of the 
> certificate. Pending action.

What was sought here was an explanation of why it took five attempts to
issue this certificate, and even the last version had problems.

> Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)
> 
> Procert:
> 
> After a validation process, we modify the RFC number in our documentation. We 
> complete this point.

I think you misunderstand. The issue here is not that some RFC number in
the document is wrong, but that your document is not arranged according
to the layout given in RFC3647. To fix this would require completely
rearranging the document. Are you saying that you have already completed
this? If so, can we see a copy of the updated document?

> Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - 
> August 2017)

> Now we stay contacting Microsoft in order to obtain and adequate procedure or 
> batch. In paralleled we work in our own OCSP software. 

I suggest that writing and deploying your own OCSP software is unlikely
to be a route towards speedy conformance with all applicable
regulations. If you are unable to get Microsoft's software to function,
I would suggest approaching another vendor. But perhaps another CA has
the Microsoft software working, and could help out? You may want to ask
on the CAB Forum list.

> Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)
> 
> Procert:
> 
> We check the standard, the OCSP certificate is SHA 256, the answer in this 
> case is an observation. We work to check and validate the adjust to SHA 256 
> in the OCSP answer. This situation does not contravene any standard.

No, but it does contradict your assertions in your responses to two
previous Mozilla CA Communications.

> Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)
> 
> Procert:
> 
> Please validate the certificate issuance. This certificate is not issued by 
> PSC PROCERT

You are quite right - my apologies. It's from a different part of the
Venezuelan Goverment's hierarchy. I was sent a large list of
certificates with this problem but a few others I've sampled also seem
to be from other parts. I will look into this and see if I can find an
example issued by PROCERT; if not, I will strike this issue.

> Issue S: Non-Random Serial Numbers (September 2016 - August 2017)
> 
> Procert:
> 
> We check the observation. Procert technical staff applied the observation and 
> fix the system in this particular point.

Please can you explain the method of construction used for the most
recent serial numbers, e.g. the one on https://crt.sh/?id=207894453?

> Issue X: High Percentage of Revocations (August 2017) 
> 
> Procert:
> 
> Staff takes actions considering the observations 

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[Gervase Markham via dev-security-policy]

Hi Connie,

On 06/09/17 20:38, cornelia.enk...@gmail.com wrote:
> SwissSign has identified the following incident:
> two Certificate signed with SHA1: Violation BR 7.3.1

Thank you for this report. There have been a couple of reasonable
follow-up questions here in the m.d.s.p. group; could you please answer
them?

> 6)
> The additional functionality introduced in January 2017 had a weak point. 
> This vulnerability was only found because of the detailed error analysis 
> performed by finding the certificate that was misissued. 
> The misissued certificates where detected by the improved quality control. No 
> further measures are currently planned.

Have automated tests been put in place to make sure the operation of
reissuing a SHA-1 certificate always fails, even after further updates
to the software?

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

Re: StartCom cross-signs disclosed by Certinomis

[Gervase Markham via dev-security-policy]

Getting back to this very late... I am studying this situation today.

On 07/08/17 10:21, Franck Leroy wrote:
> Then in November 2016 I contacted Kathleen and Gerv to know if there was some 
> stoppers to work with Inigo to help StartCom to be back in the business.
> There was no opposition as long as we follow the requirements of the 
> remediation plan. Gerv also answered that our plan was good to him.

The plan I approved was the following (quoting you):


"May be the safer solution for the interim period they have their new
root trusted, is that ;

  + we create a new subCAs with startssl names (signed by Certinomis
root) in our pki systems on a dedicated HSM.

  + startcom will only have RA access, and we can control all certs
issuance as the HSM is under our control.

  + when startssl new root is publicly trusted by Mozilla, we give the
HSM and an export of the database to Startcom.

  + then startcom cross sign the dedicated CAs with their new root, and
then they are autonomous to use the CAs their own pki system."


This seems to be very different to the plan you implemented.

In that email exchange, you asked if a cross-sign was permitted.
Kathleen replied:


"It would have to be for their new root(s) only. Definitely not allowed
for their old roots.

As always, the CA with the root cert in Mozilla's program is responsible
for ensuring that their subCAs fully comply with the CA Browser Forum's
Baseline Requirements and Mozilla's CA Certificate Policy.

I think the following from
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 would still apply:
"


Various bugs have been filed since then to suggest that StartCom has not
been following those two documents. In addition, StartCom's first
attempt at demonstrating they had met that list of action items (leaving
aside the question of whether they, in fact, have) was in mid-July:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832#c12

This was long after you did your cross-sign.

I am continuing to consider what the best next steps are in this situation.

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

Re: SHA-1 OCSP responder certificates

[Gervase Markham via dev-security-policy]

On 07/09/17 00:41, Ben Wilson wrote:
> We immediately contacted the operators of the issuing CAs and
> requested that they replace their OCSP responder certificates with
> ones signed with SHA2, and most have done so.  However, in drafting
> this post I reviewed the Baseline Requirements, section 7.1.3, which
> I think is ambiguous and allows SHA1 OCSP Responder Certificates in
> some situations.  It says, “Effective 1 January 2016, CAs MUST NOT
> issue any new Subscriber certificates or Subordinate CA certificates
> using the SHA-1 hash algorithm. CAs MAY continue to sign certificates
> to verify OCSP responses using SHA1 until 1 January 2017.

I interpret that as saying that if your OCSP responder's signing
certificate was created before 1 January 2017, and was signed using
SHA-1, you can keep using it until it expires.

However, note that Mozilla policy has some additional requirements in
this area, notably that SHA-1 certs used to sign OCSP responses must be
technically constrained to be only used for OCSP signing.

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

On 07/09/17 22:27, Ryan Sleevi wrote:
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?

I don't want to place a hard limit on it because often finding the truth
requires several rounds of interaction. But, as noted in the original
post, I would expect to be moving towards a determination of a response
in a matter of weeks (rather than months).

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

PROCERT issues

[Gervase Markham via dev-security-policy]

Mozilla has decided that there is sufficient concern about the
activities and operations of the CA "PROCERT" to collect together our
list of current concerns. That list can be found here:
https://wiki.mozilla.org/CA:PROCERT_Issues

Note that this list may expand or reduce over time as issues are
investigated further, with information either from our or our
community's investigations or from PROCERT.

We expect PROCERT to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you
are addressing on each occasion. The issues have been given identifying
letters to help with this.

At the end of a public discussion period between Mozilla, our community
and PROCERT, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about the continued trust of
PROCERT, based on the picture which has then emerged.

Gerv

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

Re: Per-intermediate CAA/problem reporting info

[Gervase Markham via dev-security-policy]

On 28/08/17 18:40, Andrew Ayer wrote:
> However, externally-operated sub-CAs generally have their own CAA
> identifiers and problem reporting information, and this information
> is not currently collected.  Would it be possible to collect this
> information on a per-intermediate basis and to publish it in
> the intermediate CA report[2]?  There could also be "same as parent"
> option, as with CPS/audit information.

This seems to make sense to me. I will investigate whether this might be
possible. It seems like having this information centrally collected is
proving useful to people.

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

Re: Remove old WoSign root certs from NSS

[Gervase Markham via dev-security-policy]

On 30/08/17 18:50, Kathleen Wilson wrote:
> https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/
> 
> I will look into getting this translated and published in China.

Here are the links to the post in Chinese, kindly supplied by our
colleagues:

http://mozilla.com.cn/thread-389981-1-1.html

http://www.toutiao.com/i6460694823383876110/

http://weibo.com/1663337394/FjOcBkk6e?type=repost#_rnd1504260080825

https://mp.weixin.qq.com/s?__biz=MTc0MDM5MjUwMQ===2651082547=1=ca6759cd7a0a035028579e7705b59e6f=547350696304d97fad4eaab40cf1d933f794525e358afc6ae40bcc1c47ff6e3007c407e0ccf0#rd

Gerv


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

Re: Adding a subCA to OneCRL when email-signing users may be impacted

[Gervase Markham via dev-security-policy]

On 01/09/17 04:47, Víctor wrote:
> But I find an issue here. The root has both websites and email trust
> bits. The subCA cert is not constrained. The representative of the CA
> want to add the subCA to OneCRL because this subCA doesn't issue TLS
> certificates. OneCRL and the CA program acts on both Firefox (if
> websites trust bit enabled) and Thunderbird (if email trust bit
> enabled). 

I don't believe Thunderbird checks OneCRL, although someone may wish to
contradict me.

> - Should CAs that ONLY have the websites trust bit get all its subCAs
> -that do not issue TLS certificates and the intermediate certificate
> is not technologically constrained- added to OneCRL just for
> prevention? Should this become mandatory?

SubCAs which are technically capable of issuing TLS certificates,
whether the CA intends for them to do so or not, need to either be
name-constrained or need to be publicly disclosed and audited. If
neither of those things is possible, we might add it to OneCRL, but this
should not be seen as a simple and first-choice solution. Better is to
make subCAs which are not intended for TLS certificates, not technically
capable of issuing them in the first place.

Gerv

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

Re: Responding to a misissuance

[Gervase Markham via dev-security-policy]

On 18/08/17 04:37, Gervase Markham wrote:
> I've started a wiki page giving Mozilla expectations and best practices
> for CAs responding to a misissuance report. (No idea why I decided to
> write that now...)
> 
> https://wiki.mozilla.org/CA/Responding_To_A_Misissuance

I have now removed the Draft designation from this document. Researchers
who find CA misissuances are welcome to include a link to this page in
their report to the CA, reminding the CA that Mozilla has the documented
expectations.

To be clear on the status of this document: this is a best practices
document, not an official policy, and does not use normative language.
Therefore, failure to follow one or more of the recommendations here is
not by itself sanctionable. However, failure to do so without good
reason may affect Mozilla's general opinion of the CA. Our confidence in
a CA is in part affected by the number and severity of incidents, but it
is also significantly affected by the speed and quality of incident
response.

Researchers may also be interested, if they have not already noticed,
that there is a ballot in preparation in the CAB Forum to adjust the
24-hour revocation rule to something more practical in cases of lower
severity.

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

Re: BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

On 22/08/17 11:02, Ryan Sleevi wrote:
> I think it'd be useful if we knew of reasons why standing up (and
> migrating) to a new infrastructure was not desirable?

It is true that in the case of a legacy root, creating a new root with a
cross-sign is not technically all that complex (although it may take
some time organizationally) and then we could embed that new one.

Given that option, perhaps a blanket statement of BR compliance for all
unexpired and unrevoked certificates is OK - allowing the CA to choose
how best to meet the requirement. (Of course, given the recent
BRpocalypse and how many CAs it affected, we may expect a new CA to need
to go through a similar process of weeding out problems.)

https://github.com/mozilla/pkipolicy/issues/99 filed.

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