RE: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec: Draft Proposal
> 
> Here is my analysis and proposal for what actions the Mozilla CA
Certificates
> module owner should take in respect of Symantec.
> 
[snip]

> Please discuss the document here in mozilla.dev.security.policy. A good
> timeframe for discussion would be one week; we would aim to finalise the
> plan and pass it to the module owner for a decision next Monday, 8th May.
> Note that Kathleen is not around until Wednesday, and may choose to read
> rather than comment here. It is not a given that she will agree with me,
or
> the final form of the proposal :-)
> 
> Gerv

Gerv, thank you for your draft proposal under consideration. We have posted
our comments and detailed information at:
https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
. 
 



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

Re: Changing CCADB domains

[Peter Bowen via dev-security-policy]

On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy  wrote:
> All,
>
> I think it is time for us to change the domains that we are using for the 
> CCADB as follows.
>
> Change the links for...
>
> 1)  CAs to login to the CCADB
> from
> https://mozillacacommunity.force.com/
> to
> https://ccadb.force.com/
>
> 2) all published reports
> from
> https://mozillacaprogram.secure.force.com/
> to
> https://ccadb.secure.force.com/
>
>
> We asked Salesforce for a temporary redirect from the old to the new URLs, 
> but that was declined because we're not paying for premium support for the 
> CCADB. (Other than this change, I do not currently see the need for us to pay 
> for premium support.)

Is it also a "premium" feature to use custom domain names?  I think it
would probably make sense to use ccadb.org (which seems to belong to
Mozilla) rather than force.com.

Thanks,
Peter
___
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

[Itzhak Daniel via dev-security-policy]

On Thursday, April 20, 2017 at 4:03:36 PM UTC+3, Gervase Markham wrote:
> Mozilla also doesn't believe that it's the job of CAs to police phishing

CAs should police as long as the browser gives positive reinforcement to the 
end-users when they access a [phishing] site.

There were suggestions in the past to remove the 'green lock' for DV/OV 
certificates. Once this is done, I believe CAs that generates those certs can 
stop "policing".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Ryan Sleevi via dev-security-policy]

Gerv,



Regarding your understanding of the “First Chrome Proposal”, which seems to
have influenced your “Alternative” suggestions, some quick clarifications:



(Wearing a Chrome/Google hat here)



The first Chrome proposal was operating on the concern that a complete and
total removal of trust in Symantec might be necessary, similar to the ones
practiced for other CAs that have issued or permitted unconstrained
intermediates. While CNNIC saw a full removal of trust relatively quickly,
and for which Mozilla produced a rather long analysis of the issues
, the
concern was that Symantec’s scale and scope prevented the immediate ability
to treat them the same, without significantly disrupting users and site
operators, and thus aimed to move the ecosystem forward on security and to
shake out the issues and impact of a full distrust.



However, recognizing the practical limitations - that a whitelist (as used
for CNNIC) would be too large, and that a notBefore block (as used with
WoSign/StartCom) would not only be inadequate for the issues (since an
intermediate can bypass those), but also be particularly disruptive (for
things such as pinning or which rely on the ubiquity of roots) - the first
proposal sought to accomplish that by gradually reducing the validity
period - first to nine months, certainly, while allowing a continued
investigation into further issues that might signal the need for total
distrust while balancing users’ needs and security. It was not an
assumption that the issues had been resolved, or that new certificates
would be fine - rather, it was based on the evidence that there were issues
and patterns that were unresolved, and thus sought to minimize the impact
of an eventual total distrust in a gradual way.



(Personally speaking from here on, and the opinions here do not necessarily
reflect that of my employer/Google)



Regarding EV certificates, your analysis of EV certificates appears to have
failed to include Issue D. In particular, in the iterations of the Final
Reports, Symantec acknowledged that their authentication team was not
properly reviewing the work of validation. That is, EV certificates are
required to have a separation of duties to ensure multi-party control
(Section 14.1.3), while Symantec’s incident report notes that:

“When testing features involving Organization or Extended Validation
certificates, our authentication team has a specific review and approval
process designed for issuance of internal-only Symantec test certificates.
The existing policy was explicit that this process should only be used for
Symantec-owned domains. That process was not followed in the issuance of
these test certificates that included non-Symantec domains. We have updated
the test certificate approval process tools and team training to ensure
that this process is only applied to the issuance of test certificates for
Symantec-owned domains“



This is also captured in “Issue 3” on https://www.symantec.com/page.
jsp?id=test-certs-update#



I’m also having trouble finding assertions or guarantees from Symantec that
at no point has any RA been involved in the issuance of EV certificates. If
Symantec is unwilling or unable to provide that assurance, or if it later
emerges that evidence of such issuance is found, does Mozilla have any
thoughts on how best to address it? More specifically - would that be a
removal of EV or a removal of trust, should such evidence emerge?



Regarding your analysis of the other incidents for precedent, you drew a
bright line around intentional deception in the case of WoSign and
StartCom, which seems a little heavy-handed. Were you thinking about their
response to the disclosure of StartCom’s sale, or to the backdated
issuance? Does Mozilla have a process for determining what is deceptive
and/or intentional? During those past discussions, there was concern that
perhaps the answers were just based on a misunderstanding of the request,
and not intentional deception. Richard Wang certainly argued this
perspective, in part, in his Incident Report regarding Issue R
.
Wouldn’t it be better to not speculate intent - and instead examine the
result and whether the expectations placed on CAs were clear and
unambiguous. In the case of WoSign, Mozilla’s policy on SHA-1 issuance was
clear, and, judging by other CAs actions, so was the policy on
acquisitions. It was also clear when Mozilla asked WoSign regarding the
acquisition what was expected.



I’m curious how you view the answers for Q9. In particular, in light of the
subsequent information disclosing that third-party RAs are involved in the
issuance of domain controller certificates, for which the publicly
available evidence suggests are indistinguishable from SSL/TLS
certificates, thus in scope of the Mozilla Certificate Policy, what was the
reasonable or common understanding of 

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi all,

This morning Symantec disclosed ~20 new intermediate certs. I went through
these and identified 7 of them which are a) not revoked, b) not expired, c)
lack a BR audit:

https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A
https://crt.sh/?q=D7D90D0FCFB5CDEC5754D663EEB3915D53703E1A29FAEEB398DCE0E22B5D4F9A
https://crt.sh/?q=58FED89E47BC48DDC659419BB64BD0862A448FCB25842F8A3FA3671FF6468F42
https://crt.sh/?q=9127783BF5190D85BC5248364145AA683EC49CD63F344721B3914E2CAF61D7A0
https://crt.sh/?q=CC6D4E8FD20599A8CC23E739774EAFB70D03B24A824C0E05D94666F5E29FC5CA
https://crt.sh/?q=DEEE5527B753A18D02BA2DAD6DFFB674CED0AF657BC0F430D4B32D97580F4D0E
https://crt.sh/?q=BC983BE6435622EF64C8EFD23084D6F8E5DCFBE9D7BCFCE6A5E51C75A29D549A

I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.

The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or there are still more. Personally, I
think this highlights the value of my earlier proposal, and I think it's
worth considering if, before any long term remediation strategies are
considered, such a rule requiring full disclosure and CT submission of all
Symantec CA certificates be implemented.

Cheers,
Alex



On Thu, May 4, 2017 at 2:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/05/2017 16:16, Gervase Markham wrote:
>
>> Here is my analysis and proposal for what actions the Mozilla CA
>> Certificates module owner should take in respect of Symantec.
>>
>> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lU
>> PmatQZwx3Sn2NPz9jF8/edit#
>>
>> Please discuss the document here in mozilla.dev.security.policy. A good
>> timeframe for discussion would be one week; we would aim to finalise the
>> plan and pass it to the module owner for a decision next Monday, 8th
>> May. Note that Kathleen is not around until Wednesday, and may choose to
>> read rather than comment here. It is not a given that she will agree
>> with me, or the final form of the proposal :-)
>>
>>
> Some notes on the text now in the document:
>
> 1. Issue D actually seems to conflate three *completely different*
>   issues:
>
>   D1) MisIssuance of actual test certificates for real world domains
>  that had not approved that issuance.  I think this was mostly the
>  old issue involving a very small number of improper in-house test
>  certs by Symantec.
>
>   D2) Dubious / non-permitted substitution of the word "test" for the
>  organization name in otherwise fully validated OV certificates as
>  a service to legitimate domain holders wanting to test Symantec
>  certificates before paying for final issuance of certs with their
>  actual name.  This was much less harmful, but was done in large
>  numbers by the CrossCert RA.
>
>   D3) Dubious and actual misussance of certificates for some domains
>  containing "test" as a substring under the direction of the
>  CrossCert RA.  These vary in seriousness but I think their total
>  number is much smaller than those in category D2.
>
>   Splitting these three kinds of "test" certificates will properly give
>   a much clearer issue of what was going on and how serious it was.
>
> 2. If the remaining unconstrained SubCAs are operated by Symantec and
>   subject to (retroactive if necessary) compliance audits showing that
>   they don't issue certs that could not (under the BR and Mozilla
>   policies) be issued from a public Symantec CA by an "Enterprise RA"
>   (as defined in the BRs), could those SubCAs not simply be
>   reclassified as "public SubCAs" for Mozilla/BR policy purposes while
>   remaining further usage limited by actual Symantec practices and
>   contractual arrangements beyond the BR/Mozilla policies?
>
> 3. The plan involving a new hierarchy outsourced to a Symantec
>   competitor leaves some big questions when seen from outside the
>   Google perspective:
>
>- Is it really necessary to outsource this to bring the Symantec PKI
> under control?  Or was this simply copy/pasted from the
> WoSign/StartCom situation?
>
>- If this is outsourced as suggested, how can/should Symantec
> continue to serve customers wanting certificates that chain to
> older CA certs in the old hierarchy.  For example some brands of
> Smartphones require that all apps installed are signed by specific
> old Symantec hierarchies via exclusivity deals that were in place
> when those Smartphones were manufactured, and no changes to that
> requirement are feasible at this point for the already sold phones.
>  Similar issues may exist in the WebPKI for jobs such as providing
> HTTPS downloads of Firefox to machines whose existing browser is
> outdated and contains an outdated root store.
>
>- Should Symantec be allowed to cross-sign SubCAs of the new roots
> 

Re: Symantec: Draft Proposal

[Jakob Bohm via dev-security-policy]

On 01/05/2017 16:16, Gervase Markham wrote:

Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.

https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

Please discuss the document here in mozilla.dev.security.policy. A good
timeframe for discussion would be one week; we would aim to finalise the
plan and pass it to the module owner for a decision next Monday, 8th
May. Note that Kathleen is not around until Wednesday, and may choose to
read rather than comment here. It is not a given that she will agree
with me, or the final form of the proposal :-)



Some notes on the text now in the document:

1. Issue D actually seems to conflate three *completely different*
  issues:

  D1) MisIssuance of actual test certificates for real world domains
 that had not approved that issuance.  I think this was mostly the
 old issue involving a very small number of improper in-house test
 certs by Symantec.

  D2) Dubious / non-permitted substitution of the word "test" for the
 organization name in otherwise fully validated OV certificates as
 a service to legitimate domain holders wanting to test Symantec
 certificates before paying for final issuance of certs with their
 actual name.  This was much less harmful, but was done in large
 numbers by the CrossCert RA.

  D3) Dubious and actual misussance of certificates for some domains
 containing "test" as a substring under the direction of the
 CrossCert RA.  These vary in seriousness but I think their total
 number is much smaller than those in category D2.

  Splitting these three kinds of "test" certificates will properly give
  a much clearer issue of what was going on and how serious it was.

2. If the remaining unconstrained SubCAs are operated by Symantec and
  subject to (retroactive if necessary) compliance audits showing that
  they don't issue certs that could not (under the BR and Mozilla
  policies) be issued from a public Symantec CA by an "Enterprise RA"
  (as defined in the BRs), could those SubCAs not simply be
  reclassified as "public SubCAs" for Mozilla/BR policy purposes while
  remaining further usage limited by actual Symantec practices and
  contractual arrangements beyond the BR/Mozilla policies?

3. The plan involving a new hierarchy outsourced to a Symantec
  competitor leaves some big questions when seen from outside the
  Google perspective:

   - Is it really necessary to outsource this to bring the Symantec PKI
under control?  Or was this simply copy/pasted from the
WoSign/StartCom situation?

   - If this is outsourced as suggested, how can/should Symantec
continue to serve customers wanting certificates that chain to
older CA certs in the old hierarchy.  For example some brands of
Smartphones require that all apps installed are signed by specific
old Symantec hierarchies via exclusivity deals that were in place
when those Smartphones were manufactured, and no changes to that
requirement are feasible at this point for the already sold phones.
 Similar issues may exist in the WebPKI for jobs such as providing
HTTPS downloads of Firefox to machines whose existing browser is
outdated and contains an outdated root store.

   - Should Symantec be allowed to cross-sign SubCAs of the new roots
directly from the old roots, thus keeping the chain length to the
old roots short?

   - Could some of the good SubCAs under the "Universal" and "Georoot"
program be salvaged by signing them from new roots and adding the
cross certs to default Mozilla and Chrome installations (so servers
don't need to install them)?  For example, if the legit EV SubCAs
under "Universal" are cross-signed by a (new) "EV-only" root, could
Mozilla move the EV trust to that new root, thus removing the
risk of EV-trusting any other "Universal" subCAs.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Changing CCADB domains

[Kathleen Wilson via dev-security-policy]

On Wednesday, May 3, 2017 at 1:21:29 PM UTC-7, Nick Lamb wrote:
> If you believe there are, or are likely to be, CAs trying to fill out the 
> survey a bit late, it may make sense to wait for that before triggering this 
> change, so as to avoid the (it seems almost inevitable) response that they 
> tried to do the survey but they were using the old link and it didn't work...


Good point. We will ask Salesforce to make this change on May 19.

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

Updating Root Program wiki pages

[Kathleen Wilson via dev-security-policy]

All,

Gerv is leading the effort to clean up Mozilla's Root Store related wiki pages.

The contents of https://wiki.mozilla.org/CA:Overview have been moved to 
https://wiki.mozilla.org/CA and cleaned up.

The previous contents of https://wiki.mozilla.org/CA have been moved to 
https://wiki.mozilla.org/CA/Application_Process

Please let me know if information that you need disappears, and you are not 
able to find it by starting with https://wiki.mozilla.org/CA 

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

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[Jakob Bohm via dev-security-policy]

On 03/05/2017 17:45, Peter Kurrasch wrote:

Perhaps a different way to pose the questions here is whether Mozilla
wants to place any expectations on the CA's regarding fraud and the
prevention thereof. Expectations beyond what the BR's address, that is.
Some examples:

‎- Minimal expectation, meaning just satisfy whatever the BR's say but
beyond that Mozilla won't care(?)

- Passive involvement, meaning a CA is expected to do some investigation
into fraudulent activity but only when prompted and even then, no action
is necessarily expected

- Active involvement, meaning the CA has implemented policies and
procedures that identify and act on situations that appear fraudulent


A question one might ask is "What is reasonable?" It is not reasonable
for CA's to identify and prevent all cases of fraud so I wouldn't ask
that. I wouldn't call CA's the anti-fraud police, either. What about the
following:

- When a CA is notified that a stolen credit card was used to purchase
certs, should the CA investigate the subscriber who used it and any
other certs that were purchased (perhaps using a different CC) and take
appropriate action?



Generally, that is entirely an economic matter between the CA, the
subscriber and the credit card clearing house used by the CA.  Most CAs
would probably revoke certificates if they suffer a chargeback,
regardless if the CC was stolen or not.

There are common best security practices that frequently prevent CAs
from actually knowing the CC numbers used by subscribers to purchase
certificates.


- Is it reasonable for any subscriber to request more than 100 certs on
a given day? What about 500? 1000? (The point is not to prohibit large
requests but I would imagine there is a level which exceeds what anyone
might consider a legitimate use case.)


Mass orders from someone who hasn't placed such orders before should be
subject to extra scrutiny as to what is going on (e.g. did we just win
a major legitimate customer from the competition?, is this a new CDN /
hosting provider with overnight success?, is there some other good
reason?).  But this may or may not be an area that Mozilla or the BRs
should set a policy for.




- Is is reasonable for a single CA to issue over 150 certs containing
"paypal" in the domain name? (I am referring to the analysis Vincent
Lynch did back in March.) There are undoubtedly cases where including
"paypal" in the name is or could be legitimate, but 150 a day, every day?



I believe this falls under the existing "High Risk Certificate
Requests" BR.


- Is it reasonable for a CA to issue a cert to the CIA for Yandex or to
the Chinese government for Facebook, even if the requester does
demonstrate "sufficient control" of the domain?



Ditto.



The point I wish to make is that situations will come up that go beyond
anything in the BR's and that reasonable people might agree go ‎beyond a
reasonable level of reasonableness. The question becomes what will
Mozilla do as those situations arise? Can Mozilla envision possibly
asking a CA "don't you think you should have limited ?"




Here is something that might be added to Mozilla Policy in lieu of
being a BR:

The criteria used by a CA to identify "High Risk Certificate Requests"
as defined by BR 1.6.1 and referenced in BR 4.2.1 shall, at a minimum
include at least, but not only, the following:

- All of the items enumerated in the BR definition of "High Risk
 Certificate Request" in BR 1.6.1, even though they may be optional in
 the current BRs.
- The Alexa top 1000 unique base domain names, (e.g. if www.mozilla.com
 and www.mozilla.org are both in the Alexa top list, they count as only
 1 when counting towards the 1000).
- The Following core Internet operational base domain names: iana,
 ietf, rfc-editor, internic, icann, example, invalid, root-servers,
 gtld-servers, arpa.
- The primary base domain names of all CAB/F members (including mozilla
 and google).
- The base domain names of all domains operated or "owned" by the CA
 itself.
- The following names that tend to indicate high value subdomain
 hierarchies: gov, com, org, co, ac.
- Anything containing the substring "bank".
- Any IDN domain names whose rendering using any of the well known
 standard fonts: "Times Roman", "Courier", "Helvetica", "Arial" is
 visually very close to any string of ASCII-only graphical characters.
 (It is noted, that this criteria can generally be checked by
 compiling a list of UNICODE code points and sequences thereof having
 this property on their own, then flagging any IDN name containing only
 ASCII plus such sequences).
- Any all-ASCII domain name containing the characters ("1", "L", "i"),
 ("0", or "o") when a different entity controls the existing domain
 formed by interchanging those with others from the same of the two
 subsets.
  For example, an application for the domain exampie.com is high risk
 from an entity other than the entity controlling exampLe.com.  And
 vice versa.

Note that "High Risk Certificate 

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Gervase Markham via dev-security-policy]

On 03/05/17 21:31, Han Yuwei wrote:
> A question:How would a domain holder express denial for certain certificate 
> requests?

Please can you post new questions as new threads rather than as replies
to existing threads on another topic?

The answer to your question is that they can define which CAs they allow
using CAA (RFC 6844) but there is no mechanism yet for them to deny e.g.
requests for a DV cert.

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