RE: GlobalSign BR violation

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Nick
> Lamb via dev-security-policy
> 
> I have a question: These certificates appear to be not only forbidden by the 
> BRs
> but also technically unlikely to function as desired by the subscriber. Did 
> any
> customers report problems which (perhaps in hindsight now that the problem is
> understood at GlobalSign) show they'd noticed the certificates they obtained
> did not work ?

I'm not aware of any communications to us about certificates they received but 
didn't work.  If they did call support then I would have assumed the order 
would have been cancelled/revoked or otherwise updated to fix the problem, but 
none of that happened.  All I can assume is that they didn't actually use it to 
secure those SANs and only used it on the CN.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Tuesday, April 4, 2017 at 10:38:28 AM UTC-7, Kathleen Wilson wrote:
> 
> The email has been sent, and the survey is open.
> 


Published a security blog about it:
https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/

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

Re: GlobalSign BR violation

[Nick Lamb via dev-security-policy]

On Tuesday, 4 April 2017 16:31:10 UTC+1, douglas...@gmail.com  wrote:
> How this happened:

Thanks Doug,

I have a question: These certificates appear to be not only forbidden by the 
BRs but also technically unlikely to function as desired by the subscriber. Did 
any customers report problems which (perhaps in hindsight now that the problem 
is understood at GlobalSign) show they'd noticed the certificates they obtained 
did not work ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Monday, April 3, 2017 at 2:21:14 PM UTC-7, Kathleen Wilson wrote:
> All,
> 
> I'm getting ready to send the April 2017 CA Communication email.
> 
> I updated the wiki page to have the survey introduction text, and a 
> (read-only) link to the full survey:
> https://wiki.mozilla.org/CA:Communications#April_2017
> 
> The survey in the Common CA Database is now open, with an expiration date of 
> May 1.
> 
> The text for the mass email is ready (see below). I have it set to be sent to 
> the CA's email alias and CC'd to the Primary Points of Contact for each CA 
> currently included in Mozilla's program.
> 


The email has been sent, and the survey is open.

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

Re: GlobalSign BR violation

[Gervase Markham via dev-security-policy]

On 04/04/17 16:31, douglas.beat...@gmail.com wrote:
> Attachment was stripped, here it the content:

Thanks Doug.

Unless anyone sees something particularly problematic here, I think we
can call this incident closed.

Gerv

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

Re: GlobalSign BR violation

[douglas.beattie--- via dev-security-policy]

Attachment was stripped, here it the content:

GlobalSign BR violation: EV Certificate with dNSName containing a space

On February 26, 2017, we received a report that there were multiple SANs in an 
EV SSL Certificate that contained a space within it.  Spaces are not permitted 
characters, per RFC 5280.  We notified the customer on March 1, 2017 and 
revoked the certificate the next day on March 2, 2017.

How this happened:

A customer ordered a certificate with CN of m.vietnamairlines.com and requested 
3 additional SANs as listed below. The base domain, “vietnamairlines.com”, was 
vetted and the certificate was then approved and issued.  When they ordered 
this 2 year certificate in August 2015 they entered a space (likely via 
copy/paste) in the SAN fields and this was not obvious the vetting team when 
they were reviewing the request.  Our ordering application did not properly 
strip out the spaces and the vetting team did not notice the space in the 
middle of these SANs.  The result was this set of invalid SAN values:
* owa. m.vietnamairlines.com
* mail. m.vietnamairlines.com
* autodiscover. m.vietnamairlines.com

Scope of the problem:

As part of this problem investigation, we went back and searched for DNSNames 
with characters that don’t comply with RFC 5280 in active certificates.  We 
found 11 orders (each with 1 active certificate) that contained values 
non-compliant with the RFC and we found one order with 34 active certificates 
(due to many certificate updates/reissuances for this order).  All have been 
revoked. 

In February 2016, we put in more comprehensive data validation for SANs and CNs 
and have not issued any non-compliant dNSName values in SSL Certificates since 
that time, until last week on March 21, 2017.  We issued a Wildcard OV SSL 
Certificate with a SAN of the format www.*.domain.com.  It has been since 
revoked.  The issue here is that the updated logic released in February 2016 
was not applied to a certain case for a certain language specific validation 
routines (we have unique server side validation routines for different 
languages and one was missed).

Plans for Remediation:

GlobalSign is continuing to improve automated compliance checking services to 
catch issues prior to issuance in a centralized location as a standard 
compliance process that all certificates will need to pass.  In addition to 
checking data when we receive new orders, we will be adding independent, 
redundant checks as follows:

* By the end of May 2017, we’ll be adding an independent post issuance check 
for 100% of issued SSL Certificates.  This centralized check can be more robust 
and will proactively detect errors so we can address them immediately.
* By the end of July 2017, we’ll be adding the same independent pre-issuance 
check in-line with the issuance process at the very last step prior to issuance 
to check issues before issuance. 

We feel that adding these 2 additional levels of checking we will eliminate 
issuance of certificates with CommonName and SAN values that do not comply with 
RFC 5280.  We plan to add redundant pre- and post-issuance validation for 
additional fields later this year.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign BR violation

[dboone--- via dev-security-policy]

On Tuesday, April 4, 2017 at 8:19:28 AM UTC-7, Doug Beattie wrote:
> Here is the incident report for this reported issue.

I don't see anything attached or linked?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign BR violation

[Doug Beattie via dev-security-policy]

Hi Gerv,

Here is the incident report for this reported issue.

Doug



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: Thursday, March 16, 2017 6:57 AM
> To: D B ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: GlobalSign BR violation
> 
> On 28/02/17 20:02, douglas.beat...@gmail.com wrote:
> > And lastly this ticket.  The Domain name was validated in accordance
> > with the BRs, but there was a bug that allowed a user entered space to
> > be included in some of the SAN values.  While the value is not
> > compliant with RFC 5280 or the BRs, there was no security issue with
> > the certificate that was issued (it was likely not able to secure the
> > intended subdomains).  We'll provide an incident report for this.
> 
> Hi Doug,
> 
> Any news on when we might see this incident report?
> 
> Thanks,
> 
> Gerv
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions for Symantec

[Gervase Markham via dev-security-policy]

On 03/04/17 13:11, Gervase Markham wrote:
> Hi Steve and Rick,

Q8) The accountant's letters for the 2015-2016 audits are dated February
28th 2017. The audits were supplied to Mozilla, and published, on the
1st of April 2017. Why the delay?

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

Root Store Policy 2.5 update

[Gervase Markham via dev-security-policy]

I've started the process of working on policy version 2.5 (does it ever
end? :-). The first thing I did was check in a number of tweaks and
wording changes which were in the April CA Communication, and therefore
had already been discussed, or which seemed uncontroversial. They are
those listed here as being checked in on April 4th (today):
https://github.com/mozilla/pkipolicy/commits/master

and the sum total of the difference is here:
https://github.com/mozilla/pkipolicy/compare/2.4.1...master

I've also triaged the remaining bugs and selected some to fix for 2.5.
They are here:
https://github.com/mozilla/pkipolicy/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.5

This is not an exhaustive list; this is all the fairly small and simple
stuff which seems to have built up. It may be that when we do all that,
we'll have enough for an update and we can do the big stuff in 2.6. Or
it may be that we then move on to the big stuff without shipping. I'm
not sure yet.

As I did for 2.4, I expect to post potential changes for discussion
weekly, in batches of around 3.

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

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 27/03/17 22:12, Andrew Ayer wrote:
> [ Corresponding issue on GitHub: 
> https://github.com/mozilla/pkipolicy/issues/67 ]

This has now been added to the policy 2.5 draft with a one-week deadline.

Gerv

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

Re: Criticism of Google Re: Google Trust Services roots

[Nick Lamb via dev-security-policy]

On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch  wrote:
> I must be missing something still? The implication here is that a purchaser 
> who is not yet part of the root program is permitted to take possession of 
> the root cert private key and possibly the physical space, key personnel, 
> networking infrastructure, revocation systems, and responsibility for 
> subordinates without having first demonstrated any competence at ‎running a 
> CA organization.

This appears to me to simply be a fact, not a policy.

Suppose Honest Achmed's used car business has got him into serious debt. Facing 
bankruptcy, Achmed is ordered by a court to immediately sell the CA to another 
company Rich & Dick LLC, which has never historically operated a CA but has 
made informal offers previously.

Now, Mozilla could say, OK, if that happens we'll immediately distrust the 
root. But to what end? This massively inconveniences everybody, there's no 
upside except that in the hypothetical scenario where Rick & Dick are bad guys 
the end users are protected (eventually, as distrust trickles out into the 
wild) from bad issuances they might make. But a single such issuance would 
trigger that distrust already under the policy as written and we have no reason 
to suppose they're bad guys.

On the other hand, if Rich & Dick are actually an honest outfit, the policy as 
written lets them talk to Mozilla, make representations to m.d.s.policy and get 
themselves trusted, leaving the existing Honest Achmed subscribers with working 
certificates while everything is straightened out, all Rich & Dick need to do 
is leave issuance switched off while they reach an agreement.

Because continuing trust is always at Mozilla's discretion if something truly 
egregious happened (e.g. Achmed's CA is declared bankrupt, a San Francisco 
start-up with four employees and $6Bn of capital buys their hardware for 
pennies on the dollar and announces it'll be issuing free MITM SSL certificates 
starting Monday morning) then Mozilla is still free to take extraordinary 
action and distrust Achmed's root immediately without waiting until Monday 
morning.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Nick Lamb via dev-security-policy]

On Tuesday, 4 April 2017 04:18:41 UTC+1, Jakob Bohm  wrote:
> So why does Mozilla want disclosure and not just a blanket X on a form
> stating that all SubCAs are adequately audited, follow BRs etc.?

Not speaking for Mozilla of course, but as a fan of disclosure provisions:

Mandating disclosure averts hypocrisy. Hypocrisy is poisonous, so we should try 
to reduce it when doing so has a reasonable cost.

Consider you're Honest Achmed. You see a business opportunity for your CA. It 
will make a lot of money, but you suspect most people will think it is wrong. 
Historically, all you needed to do was persuade yourself (and maybe a few other 
key personnel) that it's actually fine, and you're golden. If other people find 
out what you did that's a problem, but you can put that problem off until it 
happens.

Under mandatory disclosure, you have three options right up front: You can 
persuade everybody else that it's fine too, in which case it really is fine; 
You can abandon the opportunity because the risk of disapproval is 
unacceptable; You can do it anyway and hope for forgiveness, risking absolute 
distrust.

Now, a mandatory approval requirement would strengthen this by eliminating that 
last option. But it does so at an enormously greater cost as you've identified. 
Mandatory disclosure gets us most of the benefit, at a much lower cost.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy