Responses to April 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

All,

The responses to Mozilla's April 2017 CA Communication are being published here:

https://wiki.mozilla.org/CA:Communications#April_2017_Responses

Reminder:
I have postponed the response deadline to May 5, and I made a note of that here:
https://wiki.mozilla.org/CA:Communications#April_2017

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Peter Kurrasch via dev-security-policy]

  Hi Ryan--To your first comment, I'm afraid I won't have the time to take a closer look at the discussion on 3.2.2.4. Hopefully a path from single domain to unlimited domains exists (or will). It makes sense to me (without fully considering the consequences) that a "special" validation path be used for wildcards. Perhaps it could be part of an existing validation method, I'm not sure. Bottom line though, I don't think it makes sense that anyone and everyone be allowed to obtain a wildcard cert.As for the subdomain stuff, I was hoping to avoid providing some examples because I couldn't come up with a simple one. However, I think it's necessary so let's try this out:Let's suppose we break up everyone with a server on the Internet into 3 categories based on the size of their Internet presence: substantial, intermediate, and tiny. A "substantial" presence almost certainly has a large enterprise behind it with staff and capital resources to maintain the service. If we can assume that such organizations have tighter controls over use of the domain name space, servers, certificates, and so forth, then I think some of the risks posed by wildcard certs are reduced. That being the case, I'm less concerned about this category.For an "intermediate" presence, I'm thinking of places like universities that have a large number of subdomains in use but might not have a good set of controls over use of the domain name space and certificates and so forth. In this type of setting I think the use of wildcards might be appealing because it simplifies management of the network but if the controls are not in place, there remains a certain level of risk that these certs pose. (And to be fair, this isn't to say that only academic environments face this situation or that all academic environments are not suitably managed.) This category can be of concern.The "tiny" category almost speaks for itself and probably applies to all individuals and small businesses--people who want some presence but might not be all that diligent about it. In other words, these are the systems that probably have the weakest security measures in place. These are the systems that are regularly compromised and used for spam campaigns, fake login screens, and such. This is also the category for whom wildcard certs pose the greatest risk‎ to everyone else.Consider a case where someone has a custom domain--let's say easypete.ninja--and perfectly reasonable subdomains. So: - easypete.ninja  ‎- www.easypete.ninja - email.easypete.ninjaClearly there is a slight advantage for a wildcard cert in this case--it's easier than listing those subdomains. However, a wildcard cert opens up the possibility for other things like: - com.easypete.ninja - paypal.com.easypete.ninja - google.com.easypete.ninja - .easypete.ninja - facebook.com.loginassistant.easypete.ninja...and all sorts of variants of the above.‎ Per the wildcard cert, all of the above domains are perfectly valid. Per the actual intent of th‎e domain holder, most of the above are surely not valid.So, the problem becomes how a relying party may determine if the site/domain is legitimate. If I have some indicator in the browser UI that says "secure" because the FQDN matching has been satisfied, I'll probably proceed to use the page that is presented. If the indicator is missing, there is a chance I'll think twice about proceeding any further. The trouble in this situation is that if the FQDN is nefarious but satisfies the wildcard contained in the cert, I will probably make the wrong decision and open myself up to who knows what.From: Ryan SleeviSent: Tuesday, April 25, 2017 12:44 AMTo: Peter KurraschReply To: r...@sleevi.comCc: mozilla-dev-security-policySubject: Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices listOn Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy  wrote:  Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs.‎ The risk as I see it is two-fold: 1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no clear way to extrapolate a successful validation for one domain into a plethora of FQDN's in a way that works for all scenarios. So the risk in this sense is that 

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch  wrote:

> Hi Ryan--
>
> To your first comment, I'm afraid I won't have the time to take a closer
> look at the discussion on 3.2.2.4. Hopefully a path from single domain to
> unlimited domains exists (or will). It makes sense to me (without fully
> considering the consequences) that a "special" validation path be used for
> wildcards. Perhaps it could be part of an existing validation method, I'm
> not sure. Bottom line though, I don't think it makes sense that anyone and
> everyone be allowed to obtain a wildcard cert.
>

Right, but there's definitely a more careful argument you'll need to make,
because that is _precisely_ what is (effectively) desired, not just by CAs,
but most users of more than a few TLS certificates.

I'm not even sure that I disagree with you - my history in the CA/Browser
Forum hopefully demonstrates Google's deep concern with the security of the
validation methods, the capabilities possible with each validation method,
and the frequency of which they're performed. However, finding consensus
is, at this point, difficult, despite it being plainly obvious to folks
with a security background :)

For context, I've been pushing for exploring CAA methods to reduce the
permissible validation methods, and CAA already has the ability to restrict
wildcard issuance via issuewild to set a of CAs, for which you can then
establish a defined procedure. So if your concern is helping protect a
_competent_ organization from a rogue wildcard, that already exists and is
(in the process of) being required.

Let's suppose we break up everyone with a server on the Internet into 3
> categories based on the size of their Internet presence: substantial,
> intermediate, and tiny. A "substantial" presence almost certainly has a
> large enterprise behind it with staff and capital resources to maintain the
> service. If we can assume that such organizations have tighter controls
> over use of the domain name space, servers, certificates, and so forth,
> then I think some of the risks posed by wildcard certs are reduced. That
> being the case, I'm less concerned about this category.
>

Regrettably, I think this inverts the priority. "substantial" presence are
often the slowest to deploy, have the most complexity in their
infrastructure, and similarly, suffer the greatest risk from a rogue
wildcard.


> For an "intermediate" presence, I'm thinking of places like universities
> that have a large number of subdomains in use but might not have a good set
> of controls over use of the domain name space and certificates and so
> forth. In this type of setting I think the use of wildcards might be
> appealing because it simplifies management of the network but if the
> controls are not in place, there remains a certain level of risk that these
> certs pose. (And to be fair, this isn't to say that only academic
> environments face this situation or that all academic environments are not
> suitably managed.) This category can be of concern.
>

This is most organizations :)


> The "tiny" category almost speaks for itself and probably applies to all
> individuals and small businesses--people who want some presence but might
> not be all that diligent about it. In other words, these are the systems
> that probably have the weakest security measures in place. These are the
> systems that are regularly compromised and used for spam campaigns, fake
> login screens, and such. This is also the category for whom wildcard certs
> pose the greatest risk‎ to everyone else.
>

I disagree that you can attribute that cost to wildcards. That's the cost
of the organization itself. The wildcard doesn't really contribute or
change that calculus.


> ...and all sorts of variants of the above.‎ Per the wildcard cert, all of
> the above domains are perfectly valid. Per the actual intent of th‎e domain
> holder, most of the above are surely not valid.
>

CAA solves that ;)


> So, the problem becomes how a relying party may determine if the
> site/domain is legitimate. If I have some indicator in the browser UI that
> says "secure" because the FQDN matching has been satisfied, I'll probably
> proceed to use the page that is presented. If the indicator is missing,
> there is a chance I'll think twice about proceeding any further. The
> trouble in this situation is that if the FQDN is nefarious but satisfies
> the wildcard contained in the cert, I will probably make the wrong decision
> and open myself up to who knows what.
>

But that's no different than shopping Target or Home Depot and their credit
card processor / POS terminal being compromised, is it? You trusted an
organization with an insufficient security practice relative to the threats
faced. We don't say credit cards caused Target to be hacked though!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

I think this is getting weird.

At first (some other thread) it get's explained that e.g. LetsEncrypt does not 
do anything beyond domain validation and possibly on notification take down a 
few certificates of phishing site. And that was "... all OK because we want SSL 
to be used everywhere, and anyway domain validation means just that, nothing 
more..."

And now you guys are suddenly seeing problems in wild card certificates "... 
because it could be use for phishing..." Ehm, what?

Our site (category tiny) has LetsEncrypt certificates on several domain names 
and a single Comodo wildcard certificate for okaphone.com,*okaphone.com. We 
currently have the following set of domain names in the global DNS:

klant.okaphone.com
munin.okaphone.com
hans.okaphone.com
kassa.okaphone.com
ntp.okaphone.com
okaphone.com
stats.okaphone.com
svn.okaphone.com
vpn.okaphone.com
webcam.okaphone.com
www.okaphone.com

I terminate HTTPS with Pound and distribute the traffic from there to a number 
of servers (I'll spare you the details ;-). This setup gives me flexibility and 
it changes regularly for all kinds of reasons that have to do with our business.

I like it this way. Thats why I'm paying Comodo for their services. If you are 
going to make this kind of thing impossible then you are:

1) Frustrating me.

2) Causing Comodo to lose business, for I will have to use LetsEncrypt instead.

3) Putting all my eggs in one basket (there is currently no alternative for 
LetsEncrypt).

4) Not solving the problem at all, it's easy to get a certificate for a 
phishing domain from LetsEncrypt.

5) Trying to do something that certificates are not meant for. I don't think it 
is (or should be) the responsibility of CA's to verify that sites are not used 
for phishing.

I'd say, this is not a good idea at all. :-(

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

Re: Symantec Conclusions and Next Steps

[Rob Stradling via dev-security-policy]

On 25/04/17 23:50, Ryan Sleevi via dev-security-policy wrote:

Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.

More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in scope' of the audit report, as part of
https://www.symantec.com/content/en/us/about/media/
repository/Symantec-NFSSP-WTCA_11-30-2016.pdf


Hi Ryan.  Today I went hunting for missing intermediate certificates.  I 
produced a list of all the AIA:caIssuers URLs from all certs known to 
crt.sh.  Then I downloaded and parsed all of them, attempting to decode 
each file as DER cert, PEM cert, DER PKCS#7 and PEM PKCS#7.  Then I 
submitted the previously unseen certs to CT.



This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2" as within scope for this audit. It would be useful to understand their
lack of disclosure, relative to the audits and to Section 5.3.2 of the
inclusion policy.


Those two now appear here:
https://crt.sh/?id=129400172
https://crt.sh/?id=129400151

https://crt.sh/mozilla-disclosures#undisclosed currently lists these two 
SureID intermediates plus a further VeriSign intermediate 
(https://crt.sh/?id=129148836) that should've been disclosed to CCADB 
some time ago.


(Note: A few of the non-Symantec entries currently listed by 
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I 
think.  It looks like Kathleen has marked some roots as "Removed" on 
CCADB ahead of the corresponding certdata.txt update on mozilla-central).


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika--- via
dev-security-policy  wrote:

> I think this is getting weird.
>
> At first (some other thread) it get's explained that e.g. LetsEncrypt does
> not do anything beyond domain validation and possibly on notification take
> down a few certificates of phishing site. And that was "... all OK because
> we want SSL to be used everywhere, and anyway domain validation means just
> that, nothing more..."
>
> And now you guys are suddenly seeing problems in wild card certificates
> "... because it could be use for phishing..." Ehm, what?
>

Could you point to examples? I think the tone of this thread has almost
universally been consistent with the people who have said phishing isn't
for the CAs :)


> I like it this way. Thats why I'm paying Comodo for their services. If you
> are going to make this kind of thing impossible then you are:
>

Who do you believe "you guys" are?


>
> 1) Frustrating me.
>
> 2) Causing Comodo to lose business, for I will have to use LetsEncrypt
> instead.
>
> 3) Putting all my eggs in one basket (there is currently no alternative
> for LetsEncrypt).
>
> 4) Not solving the problem at all, it's easy to get a certificate for a
> phishing domain from LetsEncrypt.
>
> 5) Trying to do something that certificates are not meant for. I don't
> think it is (or should be) the responsibility of CA's to verify that sites
> are not used for phishing.
>

I think almost everyone on this thread has expressed general agreement :)

I think you may be confusing the phishing discussion (which was only
brought up once or twice) with the general _capability_/_security_
discussion, for which a wildcard certificate has unlimited capability (over
a subdomain), and thus much greater risk, and the desire to balance that
risk.

The risk is not phishing. The risk is incidental effects of compromise.
It's no different than a discussion of compromise of a technically
constrained sub-CA (which is an 'ultra-wildcard') or of an unconstrained
sub-CA/CA itself (which is a 'global-wildcard'). Each level has different
risks, and we want to make sure they're all treated accordingly. Phishing
has not been preeminent among that discussion of risks, and so if that's
your takeaway, I would say the message on this thread has been fairly
consistent in agreeing with you that certs don't solve phishing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 26 April 2017 22:43:19 UTC+2, Ryan Sleevi  wrote:
> On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika wrote:
> 
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt does
> > not do anything beyond domain validation and possibly on notification take
> > down a few certificates of phishing site. And that was "... all OK because
> > we want SSL to be used everywhere, and anyway domain validation means just
> > that, nothing more..."
> >
> > And now you guys are suddenly seeing problems in wild card certificates
> > "... because it could be use for phishing..." Ehm, what?
> 
> Could you point to examples? I think the tone of this thread has almost
> universally been consistent with the people who have said phishing isn't
> for the CAs :)

Good, I guess I simplified that to the point of not being correct anymore then. 
Just read "incidental effects of compromise" where I said phishing. It doesn't 
change what I'm saying all that much. After all LetsEncrypt can also be abused 
for this when a site has been compromised. ;-)


> > I like it this way. Thats why I'm paying Comodo for their services. If you
> > are going to make this kind of thing impossible then you are:
> 
> Who do you believe "you guys" are?

Well anybody in here in favour of doing away with wildcard certificates. It's a 
forum, anybody can join the discussion don't they? (Even though "some pigs may 
be more equal" in this context I expect. ;-)

 
> > 1) Frustrating me.
> >
> > 2) Causing Comodo to lose business, for I will have to use LetsEncrypt
> > instead.
> >
> > 3) Putting all my eggs in one basket (there is currently no alternative
> > for LetsEncrypt).
> >
> > 4) Not solving the problem at all, it's easy to get a certificate for a
> > phishing domain from LetsEncrypt.
> >
> > 5) Trying to do something that certificates are not meant for. I don't
> > think it is (or should be) the responsibility of CA's to verify that sites
> > are not used for phishing.
> 
> I think almost everyone on this thread has expressed general agreement :)
> 
> I think you may be confusing the phishing discussion (which was only
> brought up once or twice) with the general _capability_/_security_
> discussion, for which a wildcard certificate has unlimited capability (over
> a subdomain), and thus much greater risk, and the desire to balance that
> risk.
> 
> The risk is not phishing. The risk is incidental effects of compromise.
> It's no different than a discussion of compromise of a technically
> constrained sub-CA (which is an 'ultra-wildcard') or of an unconstrained
> sub-CA/CA itself (which is a 'global-wildcard'). Each level has different
> risks, and we want to make sure they're all treated accordingly. Phishing
> has not been preeminent among that discussion of risks, and so if that's
> your takeaway, I would say the message on this thread has been fairly
> consistent in agreeing with you that certs don't solve phishing.

If this is about the possible consequences of compromise, then I'd say you 
should try to adres that. But please do come up with something that still 
allows for enough flexibility, so I can arrange the HTTPS everywhere you guys 
(browsers that is ;-) want so much. At least while there is only a single CA 
(LetsEncrypt) that offers an alternative for wildcards for a reasonable fixed 
price.

After all the internet is also about variety isn't it? Seems to me there are 
not all that much CA's around... I do like the LetsEncrypt initiative but I 
also do hope they will not become the only choice. :-(

I could live with wildcards that would only work for one DNS level for 
instance. Would that be an improvement?

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

Re: Updating Bugzilla Product/Component groups for CA Program Bugs

[Kathleen Wilson via dev-security-policy]

The Bugzilla Product/Components for CA Program bugs have been changed.

All of the CA Program bugs are now in the NSS Product group in Bugzilla.

The NSS Product group in Bugzilla now has the following Components:
Build
CA Certificate Mis-Issuance
CA Certificate Root Program
CA Certificates Code
Documentation
Libraries
Test
Tools 

I am working on updating the CA Program wiki pages to match this change.

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
dev-security-policy  wrote:
>
> If this is about the possible consequences of compromise, then I'd say you
> should try to adres that. But please do come up with something that still
> allows for enough flexibility, so I can arrange the HTTPS everywhere you
> guys (browsers that is ;-) want so much. At least while there is only a
> single CA (LetsEncrypt) that offers an alternative for wildcards for a
> reasonable fixed price.
>

I'm not sure your concern - there's otherwise been broad support for
wildcards, only concerns related to the methods used to validate them to
ensure they're meaningful.


> After all the internet is also about variety isn't it? Seems to me there
> are not all that much CA's around... I do like the LetsEncrypt initiative
> but I also do hope they will not become the only choice. :-(
>
> I could live with wildcards that would only work for one DNS level for
> instance. Would that be an improvement?


They already only work for one DNS level, as a certificate. The
authorization the CA performs, however, lets them issue wildcards for any
number of subordinate subdomains - but only one wildcard in each, and each
certificate only covers a single hierarchy.

I realize that the conversation may be complex here, but I think it might
be best to simply assure you that your concerns are not misunderstood, but
more importantly, they are unwarranted, because no one is discussing
anything that would (negatively) impact the set of use cases you've
described so far. It's probably just a misunderstanding as to what's being
discussed and the subtlety of the validation points :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

[Jeremy Rowley via dev-security-policy]

Status Update: 

We are still scanning our database to discover all certificates containing 
incorrect data. So far, the count is at 1510.  The issues fall into two 
categories: 1) a failure to properly convey that BRs prohibit inclusion of meta 
data (BR 7.1.4.2.2.j) and 2) auto-population of data in the order that 
validation forgot to clear before issuing the certificate. 

On the training issue, the validation team inserted characters like "-", "." or 
other similar information in approximately 1000 certificates. This information 
asserted that the field was not applicable. The remaining 500 included 
auto-population data. The auto-population took three formats (such as a number 
representing the country code) depending on the customer's location and access 
to our certificate management platform. Interestingly, the validation database 
contains the correct documentation. However, we failed to properly update the 
certificate information to match the validated data.

Since Mike reported the issue, we've patched our system to prevent meta-data 
and made substantial improvements to the validation process. These improvements 
help identify mis-matches between validation information and certificate data.

We also started the revocation process for the 500 certificates containing 
meta-data. However, we wanted to ask about the 1000 certificates containing 
data indicating the field was not applicable. We recognize these were not 
properly issued, but I am curious whether revocation is required by Mozilla in 
this case. Should we start revoking those certificates as well despite the 
certificate information clearly not indicating a state/province? My thought is 
yes because of BR 4.9.1.1:

9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the
CA’s Certificate Policy or Certification Practice Statement;

I don't think #10 applies because the information is accurate - the field is 
not applicable:
10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading;

Thoughts? 

Jeremy


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, April 20, 2017 6:11 PM
To: mozilla-dev-security-policy 
Subject: RE: CA Validation quality is failing

Thanks Mike for bringing this up. We’ve looked into it and have an initial 
report to share.

After receiving the email on the Mozilla list, we investigated the identified 
certificates and discovered a couple of very related issues in our process that 
led to certificates with bad info:
1. As Jakob pointed out, part of the issue was that our intake form required a 
state if US was selected. As country is the last requested field, the state 
only became optional after the customer completed the rest of the form. This 
led to a lot of customers submitting bad data.  
2. We have an old tool that generates information based on a customer’s 
location. This tool helps customers create CSRs and complete certificate 
requests. The tool inserts bad data into some fields if the field is left blank 
by the customer. The result was customers using this tool outside of the US had 
numbers included in the state field.  
3.  There was a gap in our validation process. This is the more important issue 
as the validation process should have caught the bad data inserted by the other 
two issues. Although we are obtaining validation documents from the appropriate 
government entity, the data submitted via the tool or intake form was not 
properly being updated with retrieved validated information. The end result was 
that the bad CSR data was submitted for signing instead of the data listed on 
the government document. This was a personnel problem, not a failure in our 
system as the validation staff was not appropriately updating the required 
signing fields.

So far, we have identified approximately 600 certificates that have the wrong 
state, zip, or locality. This is just a measurement of the problem scope and 
not the exact number as we are still reviewing are certificate database using a 
mapping API to determine whether the address exists. We expect the search to 
have a lot of false positives initially but provide a maximum scope of the 
problem. In parallel, we are contacting each customer with a non-compliant 
certificate, replacing the certificate, and revoking the certificate.  All 
mis-matched certificates are being uploaded to the Google and DigiCert CT logs. 

To fix our process, we are planning the following:
a.  We are immediately deprecating our geolocation tool and updating our intake 
form to help reduce the amount of bad data. 
b. We are updating our validation process to flag the differences in validation 
data and customer-provided data. 
c. We are providing our validation staff with an extra mandatory tool that 
checks address info

Expanding Aaron Wu's role in CA Program

[Kathleen Wilson via dev-security-policy]

All,

As many of you know, Aaron Wu has been doing the Information Verification[1] 
for root inclusion/update requests, has helped me organize the CA Program 
Bugzilla Bugs[2], and continues to expand in his role in helping with Mozilla's 
CA Certificates Module[3]. 

I have asked Aaron to begin opening the public discussions[4] for root 
inclusion/update requests, and to help me keep those discussions moving 
forward, so we can work through our queue[5].

For further information, please see the entry I added for Aaron in the 
CA:Policy_Participants wiki page[6].

I will continue to be very involved in the CA Program, but as you may have 
noticed I became overloaded this year. Therefore, I am extremely grateful for 
all the work that Gerv and Aaron have picked up.

I will greatly appreciate your understanding and support to help Aaron as he 
takes on more of this work.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
[2] https://wiki.mozilla.org/CA_Bug_Triage
[3] https://wiki.mozilla.org/Modules/All#CA_Certificates
[4] https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
[5] https://wiki.mozilla.org/CA/Dashboard#Ready_for_Public_Discussion
[6] https://wiki.mozilla.org/CA:Policy_Participants
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
> 
[snip]
> 
> Symantec have also written to Mozilla to say the following:
> 
> "We have been working hard on a thorough and thoughtful proposal that
> responds to community questions and concerns regarding our compliance
> and issuance practices. In drafting this proposal, we’ve thoughtfully
> considered the feedback posted on the Mozilla forums along with comments
> on the Google forums and other community feedback. We’ve also solicited
> input from our customers who are the ones that would bear the impact of
> changes, whether as a result of our proposal or any other.
> 
> We plan to send a proposal for Mozilla’s and the community’s consideration
> on Wednesday April 26th that addresses these important areas:
> 
> * The Integrity of our EV Validation Process
> * Validity of Existing Certificates
> * Increased Transparency
> * Move to Shorter Validity Certificates
> * Continuous Improvement of our CA Operations"
> 
> This date is in the middle of next week. We permitted WoSign to propose a
> remediation plan; I think it is reasonable to do the same for Symantec. So we
> will wait to hear what they have to say, and then discuss appropriate action 
> in
> the light of it.
> 
> Gerv
> 

Symantec CA Response to Google Proposal and Community Feedback

We take our role as a key player in the trust ecosystem of the Internet very 
seriously. We believe that secure and compliant issuance of SSL/TLS 
certificates is fundamental to the security of the Internet and that we have a 
responsibility to collaborate with our customers and the broader community to 
continuously improve industry standards, and specifically our practices, for 
certificate issuance. 

On March 23, Google posted a blog outlining a proposal to change how Symantec’s 
SSL/TLS certificates are recognized in Chrome. Their proposal stemmed from 
prior certificate mis-issuances that occurred in our Certificate Authority (CA) 
business, which we have taken extensive remediation measures to correct. We 
have carefully reviewed Google’s proposal and sought input from the broader 
browser and user community on this topic, which has informed our continuous 
improvement planning. This post outlines important measures that we propose to 
implement in our CA business. We believe our proposal addresses the concerns 
raised by Google about our CA business without imposing undue business 
disruption on our customers and Chrome users that we believe would result if 
Google implements its proposal. 

Feedback from our Enterprise Customers 

In addition to our review of public commentary on these issues, we have also 
sought input and feedback from Symantec customers on the compatibility and 
interoperability impact of the significant changes that could result from the 
implementation of Google’s proposal. These customers include many of the 
largest financial services, critical infrastructure, retail and healthcare 
organizations in the world, as well as many government agencies. This cohort is 
an important constituency that we believe has been under-represented to date in 
the public commentary that has been posted to the Google and Mozilla boards 
since large organizations rarely authorize employees to engage in such public 
discussions, particularly in an area related to security. We first solicited 
feedback to understand the disruption that a browser-initiated trust change, 
like the one proposed by Google, would cause organizations that opt to replace 
their existing SSL/TLS certificates in order to maintain interoperability with 
all browsers. We learned that these organizations’ publicly facing web 
applications, while extensive, only represent a fraction of their dependency on 
publicly trusted Symantec roots. Many large organizations have complex, and 
potentially undocumented and little-known dependencies on their certificate 
infrastructure. Examples of complex dependencies on Symantec public roots that 
our customers have shared or we have identified include:

- Embedded devices that are pinned to certificates issued by a Symantec public 
root to communicate to resources over the Internet or Intranet. Replacing these 
certificates would result in immediate failures and the need to recode and 
reimage the firmware for these devices.
- Mobile applications that have pinned certificates. Replacing server 
certificates would require these applications to be recoded, recompiled and 
redistributed.
- Critical infrastructure organizations that use certificates issued off of 
Symantec roots to validate internal and external resources. In many cases the 
applications being used are pinned to Symantec certificates.
- Some large organ

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 27 April 2017 00:42:20 UTC+2, Ryan Sleevi  wrote:
> On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
> dev-security-policy  wrote:
> >
> > If this is about the possible consequences of compromise, then I'd say you
> > should try to adres that. But please do come up with something that still
> > allows for enough flexibility, so I can arrange the HTTPS everywhere you
> > guys (browsers that is ;-) want so much. At least while there is only a
> > single CA (LetsEncrypt) that offers an alternative for wildcards for a
> > reasonable fixed price.
> >
> 
> I'm not sure your concern - there's otherwise been broad support for
> wildcards, only concerns related to the methods used to validate them to
> ensure they're meaningful.
> 
> 
> > After all the internet is also about variety isn't it? Seems to me there
> > are not all that much CA's around... I do like the LetsEncrypt initiative
> > but I also do hope they will not become the only choice. :-(
> >
> > I could live with wildcards that would only work for one DNS level for
> > instance. Would that be an improvement?
> 
> 
> They already only work for one DNS level, as a certificate. The
> authorization the CA performs, however, lets them issue wildcards for any
> number of subordinate subdomains - but only one wildcard in each, and each
> certificate only covers a single hierarchy.
> 
> I realize that the conversation may be complex here, but I think it might
> be best to simply assure you that your concerns are not misunderstood, but
> more importantly, they are unwarranted, because no one is discussing
> anything that would (negatively) impact the set of use cases you've
> described so far. It's probably just a misunderstanding as to what's being
> discussed and the subtlety of the validation points :)

Well, sorry I misunderstood then. And thanks for reassuring me. ;-)

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